Le 9 sept. 2013 à 11:54, Tom Davie <tom.da...@gmail.com> a écrit :
> > On 9 Sep 2013, at 11:49, Jean-Daniel Dupas <devli...@shadowlab.org> wrote: > >> >> Le 9 sept. 2013 à 11:33, Tom Davie <tom.da...@gmail.com> a écrit : >> >>> >>> 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). >> >> 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. Interesting. Actually, after doing a naive ARC migration I find a 30%slow-down on this sample. It look like the main slowdown is induced by an increase of retain/release calls introduced by extra-safety. Each time you send a message to an object, the compiler assumes the object may be released by the message, and so if you need to use this same object again after the message, the compiler make sure it was not released by including a retain/release. For instance, CPItem isEqual: method implemented like this: [object isItem] && (object->xxx == xxx) ends up generating something like this: object_retain(object); [object isItem] && (object->xxx == xxx) object_release(object), And such method are in hot path (as they are used for hash collection lookup). Unfortunately, I don't know how to tell the compiler to avoid this useless safety. -- Jean-Daniel _______________________________________________ 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
