On Jun 24, 2009, at 22:49 , Greg Titus wrote:
...whereas this part talks specifically about the collector. Is
there a downside in SnowLeopard to CFRetain/CFRelease when not
using the collector?
There's no _new_ downside to CFRetain/CFRelease. It's just the
existing downside (collected process or not) that CFRetain/CFRelease
are function calls that need to be made and code that needs to be
executed,
You do realize that assignments under GC generate function calls? So
while you don't see them in your code, they still do get executed.
And if you use accessors and let your accessors be generated (by
@synthesize or accessor macros), the difference is negligible.
and, what's more, retain/release needs to be thread-safe, which adds
a bit more to the expense.
Yep.
The important word in what Bill was saying is "concurrently". The
garbage collector can work concurrently in another thread, so your
tight loops in your compute thread(s) do less work (no CFRetain/
CFRelease)
My tight loops tend not to have retains/releases, because I tend to
lift expensive operations out of performance-sensitive inner loops.
But that's just me.
, and you get a performance advantage because your code is able to
take more advantage of multiple cores, since memory is reclaimed in
a separate thread, rather than that work being interleaved in your
code in the compute thread(s).
That is a theoretical advantage (unless you are concerned about power
consumption). To be practical, the overhead of running the extra
thread and the overhead of the in-thread GC code must be less than the
overhead of RC. Measurement helps answer that question.
Marcel
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
