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

Reply via email to