On 9 Sep 2013, at 10:18, Jean-Daniel Dupas <devli...@shadowlab.org> wrote:
> > Le 9 sept. 2013 à 09:58, Tom Davie <tom.da...@gmail.com> a écrit : > >> >> On 9 Sep 2013, at 09:44, Kyle Sluder <k...@ksluder.com> 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 <a...@webis.net> 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 (j...@mooseyard.com) 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). It’s fair to say that large chunks of this code could be optimised by removing a bunch of object allocation/deallocation, but I think it’s fairly representative of the style most obj-c code will be written in, and hence a pretty fair test. > 100 % slowdown! i suggest you push the Continue button after hitting your > breakpoint :) > > Joking apart, i am surprised that you find things slower, but i never did any > adequate performance comparisons myself. Yes, I too was surprised by that, this was in fact the first example I tried profiling, so I was even more surprised, and went out and tested a bunch more bits of code. > I don't know what it is like to convert an old project, but I would recommend > ARC for new projects and I believe the time investment is worthwhile. For me the distinction is more along performance lines. If you’re dealing with code that you’re already thinking “hmm, rewriting the cores of this in C, rather than high level obj-c would get me a nice performance gain”, then ARC is probably not for that code. If on the other hand, you’re writing an application that does normal interactions with the user, that’s presenting bits of UI, and grabbing data from the internet, and not really doing much CPU intensive stuff, then ARC is almost certainly a major boon for that code. Tom Davie _______________________________________________ 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
