On Sep 9, 2013, at 4:15 AM, Marcel Weiher <marcel.wei...@gmail.com> wrote: > On Sep 9, 2013, at 11:33 , Tom Davie <tom.da...@gmail.com> wrote: >>> On 9 Sep 2013, at 10:18, Jean-Daniel Dupas <devli...@shadowlab.org> wrote: >>> >>> And does the profiler explicitly shows that ARC runtime code is the culprit >>> ? >> >> Yes, it does. > > Isn’t it strange how when someone says “oh, and ARC is faster”, without > measurements, that passes without comment?\\
I believe you’ve been on this list long enough to know that nothing ever passes without comment. >> [] 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 shouldn’t really be surprising. ARC adds an astounding number of > additional reference counting ops to all code involving object pointers. If > that were compiled, ObjC would be completely unusable and slower than all the > so-called scripting languages out there. So for things to be usable, ARC > then has the optimizer try to undo most of the damage and finally adds some > clever runtime hacks to mitigate the rest. > > Since the hacks and the remaining damage are somewhat orthogonal, you > sometimes end up ahead and sometimes you end up behind. > > The other thing that should be considered when seeing heroic hacks like the > autorelease-undoer is that such techniques rarely arise spontaneously from an > idle moment of relaxed performance optimization. More usually, they happen > because there is some sort of “ho lee f*k” moment, where performance > regression is so bad/project-threatening that something drastic/heroic needs > to be done. For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. But most of these micro-optimizations are achievable within ARC by adding a few __unsafe_unretained annotations. Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases" workarounds like literally making every temporary variable a property is basically asking to be pessimized. It’s a happy coincidence that, in this case, a better code style corresponds to better performance. Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Ultimately, ARC is just a tool for improving your productivity as a programmer, not a magic button with no downsides. John. _______________________________________________ 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
