On Sep 11, 2013, at 12:03 AM, Marcel Weiher <marcel.wei...@gmail.com> wrote: > 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. :-)
Fortunately. :) >> 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. :-) I think we’re in agreement here. > 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?) > > 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) Right. ARC doesn’t replace the benefit of having an inline reference count. I think if we could magically bless all objects with an inline reference count without worrying about disrupting existing hard-coded object layouts, we probably would. >> 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! We’ve definitely seen some odd contortions to avoid a few explicit retain/releases. >> 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? Absolutely. We’ve found that it usually doesn’t take very many __unsafe_unretained annotations to eliminate most regressions. There are a ton of places where any human reading the code would immediately realize that an object won’t get released, but ARC can’t quite prove that, usually because there’s an intervening message send. Most of those places don’t detectably affect performance; it’s the one or two that happen in a loop and therefore trigger 40,000 times that you notice. But by the same token, those sites tend to show up in Instruments and so are easy to track down and fix. 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
