Re: ARC vs Manual Reference Counting
Re: ARC vs Manual Reference Counting
- Subject: Re: ARC vs Manual Reference Counting
- From: James Montgomerie <email@hidden>
- Date: Mon, 09 Sep 2013 14:30:26 +0100
When performance testing ARC code, remember to test in a release configuration, with compiler optimisations on. In my experience, it can really make a big difference; a lot of 'spurious' retain/release pairs are optimised away, and many objects are released earlier.
Jamie.
On 9 Sep 2013, at 11:15, Kevin Meaney <email@hidden> wrote:
>
> On 9 Sep 2013, at 10:33, Tom Davie <email@hidden> 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 (email@hidden)
>
> 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:
>
> This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden