Hi John! On Sep 10, 2013, at 19:26 , John McCall <rjmcc...@apple.com> wrote:
> On Sep 9, 2013, at 4:15 AM, Marcel Weiher <marcel.wei...@gmail.com> wrote: >> [Optimizations in ARC are there to mitigate pessimizations] > > 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. Glad to hear that the performance problems that the optimizations were designed to mitigate were identified early, hope this also resulted in fewer Café Macs dinner tickets. :-) > 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. I don’t think that would be a good target or reason for opting out. In fact, I have a protocol where I have a +1 return that I am thinking of turning ARC on for so I don’t have to do that any longer. :-) More likely performance reasons/targets for opting out are things like inline reference counts and, especially, object caches. For me they generally bring factors of improvement, if not orders of magnitude, when applicable (wasn’t it CoreGraphics that had problems with their object cache no longer working on GC, thus killing performance?) Being able to mix-n-match and opt out is definitely one of the awesome features of ARC. On the inline reference counts: when I was doing my recent tests on archiving performance, I suddenly found that object creation (1M objects) was taking longer than expected. Adding an inline retain count *halved* the running time for creating the object graph (155ms vs 300ms)! I have to admit I was bit surprised that the difference would be this big, considering the intrinsic cost of object creation. (Out of curiosity I tested it with ARC and it took 400ms) > 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. You misunderstand (I am likely blame for that for not expressing myself clearly): the temporary variables I use accessors for are the (very few) ones that have strange enough lifetimes that you see retain/release code for them in the middle of methods. Quite often, they already live in instance variables, but are just accessed in an ad-hoc fashion. Using accessors for them really is (or should be) a no-brainer. Sometimes there are asynchronous loops that use a local variable in a similar fashion. Using instance variables for ALL method temporaries would be silly…in essence it would be using the ARC strategy, but without the optimizer running to get rid of most of the damage, ouch! > 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, That is also what I would have expected, given what I know about it. It’s interesting that the “group consensus” I find both on the webs/tutorials and also here, sometimes tacit, sometimes not, is that ARC is a performance win. Note how the claim that ARC was faster went unremarked, whereas the finding of a slowdown created immediate negative reaction (“did you test?”, “you must have made a mistake”), fortunately mostly in good humor. > 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. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? > Ultimately, ARC is just a tool for improving your productivity as a > programmer, not a magic button with no downsides. ;-) Cheers, Marcel _______________________________________________ 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
