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. 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
