On 9 Sep 2013, at 10:33, Tom Davie <tom.da...@gmail.com> wrote: > > Yes, it does. If you’d like an example to verify this behaviour with, play > with converting https://github.com/beelsebob/CoreParse to ARC, and profiling > the result. This is the example that showed 100% slowdown initially. The > last time I tried this with with Xcode 4.5, and after I’d added a bunch of > extra autorelease pools all over the place which reduced ARC’s overhead to > “only" 50%. This in itself suggests to me that ARC causes a significant > increase in the number of autoreleased objects (which surprised me given the > runtime optimisation to get rid of autorelease/retain pairs in callee/caller).
One of the things that has changed in the code that I write, is that in manual retain/release I would often use the autorelease class methods for creating an object arrayWith... etc. and think about the placement of autorelease pools. Using ARC I almost never use these class methods for creating an object but instead use alloc init. I don't have a lot of temporary objects hanging around now. My new project is still so far from ready that optimizing at this point is not sensible. I do have however a bunch of utility functions that do a lot and currently use cocoa for doing the work but that nearly all the cocoa can be replaced by their toll free bridged core foundation equivalents. So if measurement proves that a lot of time is spent in these methods I'll rewrite them then. Kevin _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
