Does it make a difference in performance if I use self.fooBar instead of fooBar?_问答_开发者

Note: I know exactly what a property is. This question is about performance.

Using self.fooBar for READ access seems a waste of time for me. Unnecessary Objective-C messaging is going on. The getters typically simply pass along the ivar, so as long as it's pretty sure there will be no reasonable getter method written, I think it's perfectly fine to bypass this heavy guy.

Obj开发者_StackOverflow社区ective-C messaging is about 20 times slower than direct calls. So if there is some high-performance-high-frequency code with hundreds of properties in use, maybe it does help a lot to avoid unnessessary objective-c messaging?

Or am I wasting my time thinking about this?

This kind of premature optimization should really be postponed until you actually notice or measure (with Instruments.app) a real problem.

No offence, but you're probably wasting your time thinking about it. Unless you have code that accesses that property thousands of times a second, then you're not going to see any performance differences.

The two aren't really interchangeable (ok some of the times they are). Access the ivar directly when that is what you need and use the accessor methods when that is what you need. It will probably depend on the the class hierarchy, the implementation of the class, is the code thread safe etc, etc.

All things that are largely upto you if it's your code. Might someone want to subclass this class and write a custom implementation of -foobar that always returned @"BOO" but they find that the superClass method -printFooBar now prints @"hello darling" because it prints out the value of the variable foobar instead of the value returned from self.foobar ?

Calling the accessor method does have more overhead than using the variable directly, but there are more things to consider than performance. Personally i find the position "always use the accessor method" just as ridiculous as saying "never use the accessor methods" - which would clearly be ridiculous.

Yes using property getters are much slower than direct access. A property getter is useful outside of the self class (and categories) for encapsulation, but I see no benefits using a self.ivar getter, unless you have overridden the getter to something else.

(And why are you using self.ivar in the first place?)

The only cases where self.ivar will be different from self->ivar are:

The property is atomic, so self.ivar will be similar to

spin_lock(&ivar_lock);
id retval = [ivar retain];
spin_unlock(&ivar_lock);
return [retval autorelease];

for an id property, and

spin_lock(&ivar_lock);
spin_lock(&destination_lock);
memcpy(&destination, &ivar, sizeof(ivar));
spin_unlock(&ivar_lock);
spin_unlock(&destination_lock);

for a struct. There is no difference between the two when the property is nonatomic.

When the class is not final. A category of the class or a subclass can override the property getter to something else. But I think overriding a concrete property is not a good style.

Like what the others have said, unless you have tested that the getter is a hot spot, changing it back to direct ivar access won't help much.

Some may disagree, but I happen to like accessing the ivar directly and bypassing the whole messaging business where possible. I think it makes my intentions clearer, since if I ever need to message the getter (for memory management or the like), then I will.

It's a tiny bit less efficient, but you still should generally not make your object state public. Although public members are considered bad in most OO languages, there's actually a pragmatic reason why in Objective-C: The framework uses your "getter" and "setter" methods to make certain things automatic, such as memory management and KVO notifications. With ivars accessed from multiple places, every piece of client code needs to fully understand all the responsibilities that the accessor methods were taking on and perform those duties in the exact same way itself.

So it's no "absolutely don't access your own ivars," but just make sure you fully understand what it entails in a given situation.