Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: when do you use properties vs. ivars?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: when do you use properties vs. ivars?

On Mar 17, 2013, at 12:27 PM, Jens Alfke <email@hidden> wrote:
On Mar 16, 2013, at 4:32 PM, Olivier Larivain <email@hidden> wrote:

- how much faster overall, not in a micro benchmark, in either reactivity/speed and battery life? Do you have numbers to share on the overall impact?

I don’t personally have numbers. While I was still at Apple, the WebKit team did find that they were hitting performance bottlenecks in fundamental Obj-C runtime constructs like method dispatch and retain-release, and rewrote a bunch of code to be lower-level.

I’ve spent a bunch of time optimizing code, and the things I fear aren’t so much the parts of my code that turn out to be using a slow algorithm or caching too much or too little — you can easily track those down and rewrite them more efficiently. The scary stuff is the subtle 'death by a thousand cuts' of small inefficiencies spread out everywhere in the code in ubiquitous operations like property access. You can’t really find them through profiling because they make _everything_ in your app proportionally slower, so they don’t stick out as hot-spots.

Right.  There are a lot of things that are hard to individually measure but which make a noticeable difference in the aggregate.

Properties affect performance in a lot of ways:
1. As already discussed, sending a message to do a load/store is slower than just doing the load/store inline.
2. Sending a message to do a load/store is also quite a bit more code that needs to be kept in i-cache:  even if the getter/setter added zero extra instructions beyond just the load/store, there'd be a solid half-dozen extra instructions in the caller to set up the message send and handle the result.
3. Sending a message forces an entry for that selector to be kept in the method cache, and that memory generally sticks around in d-cache.  This increases launch time, increases the static memory usage of your app, and makes context switches more painful.  Since the method cache is specific to the dynamic class for an object, this problem increases the more you use KVO on it.
4. Sending a message forces all values in the function to be spilled to the stack (or kept in callee-save registers, which just means spilling at a different time).
5. Sending a message can have arbitrary side-effects and therefore forces the compiler to reset all of its assumptions about non-local memory.
6. A message send can have arbitrary side-effects and therefore cannot be hoisted, sunk, re-ordered, coalesced, or eliminated.
7. In ARC, the result of a message send will always get retained, either by the callee or the caller, even for +0 returns:  even if the method doesn't retain/autorelease its result, the caller doesn't know that and has to try to take action to prevent the result from getting autoreleased.  This can never be eliminated because message sends are not statically analyzable.
8. In ARC, because a setter method generally takes its argument at +0, there is no way to "transfer" a retain of that object (which, as discussed above, ARC usually has) into the ivar, so the value generally has to get retain/released twice.

None of this means that they're always bad, of course — there are a lot of good reasons to use properties.  Just keep in mind that, like many other language features, they're not free.

Do not post admin requests to the list. They will be ignored.
Objc-language mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

 >when do you use properties vs. ivars? (From: "Patrick J. Collins" <email@hidden>)
 >Re: when do you use properties vs. ivars? (From: OC <email@hidden>)
 >Re: when do you use properties vs. ivars? (From: Jens Alfke <email@hidden>)
 >Re: when do you use properties vs. ivars? (From: Olivier Larivain <email@hidden>)
 >Re: when do you use properties vs. ivars? (From: Jens Alfke <email@hidden>)

Visit the Apple Store online or at retail locations.

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.