Re: ARC vs Manual Reference Counting
Re: ARC vs Manual Reference Counting
- Subject: Re: ARC vs Manual Reference Counting
- From: Tom Davie <email@hidden>
- Date: Mon, 09 Sep 2013 11:54:03 +0200
On 9 Sep 2013, at 11:49, Jean-Daniel Dupas <email@hidden> wrote:
>
> Le 9 sept. 2013 à 11:33, Tom Davie <email@hidden> a écrit :
>
>>
>> On 9 Sep 2013, at 10:18, Jean-Daniel Dupas <email@hidden> wrote:
>>
>>>
>>> Le 9 sept. 2013 à 09:58, Tom Davie <email@hidden> a écrit :
>>>
>>>>
>>>> On 9 Sep 2013, at 09:44, Kyle Sluder <email@hidden> wrote:
>>>>
>>>>> Thirded. I thought I wouldn't like it. As soon as I didn't have to manage retains and releases of temporary objects, the discipline completely left my mind. Now whenever I go back to non-ARC code I invariably make a ton of memory management errors, most of which are caught by the analyzer.
>>>>>
>>>>> --Kyle Sluder
>>>>>
>>>>> On Sep 8, 2013, at 11:18 PM, Alex Kac <email@hidden> wrote:
>>>>>
>>>>>> Bingo. We’ve been working with Cocoa/Obj-C for many years, and still we’d find weird errors that would be caused by some over-released object. We cut a ton of code with ARC, and in the end we saw reliability go up and actually even some performance.
>>>>>>
>>>>>> ARC is a win. The only place it really got a bit hairy was CF objects. I wish ARC would work with them a bit more.
>>>>>>
>>>>>> On September 8, 2013 at 11:56:10 PM, Jens Alfke (email@hidden) wrote:
>>>>>>
>>>>>> They’re a _lot_ easier. It might not look that way when you’re reading about all the details, or converting existing code, because then you’re focusing on the rare edge cases. But for the most part when actually coding you can simply ignore ref-counting. Your code becomes more compact and readable, and you’re less likely to make mistakes.
>>>>
>>>> I *completely* agree with you with regards to memory management being hard to get reliably right (not hard to get right, hard to get reliably right), and weird errors all the time caused by memory management going wrong. ARC is a major boon in this regard.
>>>>
>>>> However, I have to say, I have had the complete opposite experience with regards to performance. Having measured various projects before and after converting to ARC, I have seen numbers between 30% and 100% slowdown with ARC. The average is probably around 50%. I have never seen performance improve when using ARC.
>>>
>>>
>>> And does the profiler explicitly shows that ARC runtime code is the culprit ?
>>
>> 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).
>
> I'd be interested to dig a little further in what cause the slowdown. Do you have some sample code/file that can be used to stress the library and profile it ?
Sure, there’s a simple example at https://github.com/beelsebob/ParseTest/, alternatively, you can profile the test cases included with CoreParse.
Tom Davie
_______________________________________________
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