On Jun 24, 2009, at 10:38 PM, Marcel Weiher wrote:
On Jun 24, 2009, at 11:00 , Bill Bumgarner wrote:
On Jun 24, 2009, at 12:51 PM, Quincey Morris wrote:
In a nutshell, for folks like me who regularly use CFCreate …
CFRelease in loops, what are the benefits of GC?
If CFCreate/CFRelease is precisely what you want to do, there are
no benefits from GC, because the garbage collector isn't involved.
Similarly, if you regularly use alloc/init ... release in loops,
there are no benefits from using autorelease instead of release
(in a non-GC app, I mean).
However, if the lifetime of the object you CFCreate is not
strictly internal to the loop, then using (in a GC app)
CFMakeCollectable once instead of futzing with CFRelease in
multiple paths of execution might simplify your code greatly.
There are actually some performance downsides to using CFRetain/
CFRelease in Leopard that grow to a greater significance in Snow
Leopard. In Snow Leopard, this includes short lived objects like
the temporaries that may be CFCreate'd/CFRelease'd in a tight loop
(obviously, I can't disclose what those changes are -- if you are
curious, post a question to devforums.apple.com).
Hmm...this part of the answer indicates a generic downside...
Specifically, you are effectively disabling the Collector's ability
to do collection work, including object reclamation and
finalization, concurrently with the execution of code that actually
does work.
...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, and, what's more, retain/release needs to be thread-safe,
which adds a bit more to the expense.
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), 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).
- Greg_______________________________________________
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
