Le 11 sept. 2013 à 09:03, Marcel Weiher <marcel.wei...@gmail.com> a écrit :
> 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. I think this common misbelief come from the fact that when Apple released ARC, they have claimed a non negligible performance win for retain/release and autorelease operations. While this is true, it does not give any clue about the global impact of ARC. > >> 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? > Yes. it works to disable ARC for arguments and other local variables. I managed to reduce the ARC impact a little further by applying it to some arguments in hot paths. -- 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
