Objective-C properties - uses [self myProperty] or self.myProperty slower than myProperty?

Question

I use Objective-C properties to handle save / release instance variables for me. In my class, I do things like this:

self.myProperty = somethingIWantToRetain [self.myProperty doSomeAction] [self.myProperty doSomethingElse] 

Uses [self myProperty] /self.myProperty more slowly than just using myProperty for those lines where I do not change the value of myProperty? For example, will it be faster?

 self.myProperty = somethingIWantToRetain [myProperty doSomeAction] [myProperty doSomethingElse] 

thanks

Answer 1

This is almost certainly a little slower, but it is unlikely to be of much importance.

Addressing your ivar directly (with open voice myProperty ), it accesses the variable directly. Referring to your getter (with equivalent self.myProperty or [self myProperty] ), you need to call a method that normally executes retain and autorelease on your ivar.

However, sending a method to Objective-C is very, very fast, and saving / answering calls are also quite cheap, especially for objects that are most likely not to be destroyed when clearing the auto-calculation pool. I would focus on readability and consistent style, and only worry about performance here when it becomes clear that you have performance bottlenecks to pursue.

Answer 2

To be precise, when you write [myProperty doSomeAction] , you do not actually access this property, but directly access the instance variable (used as the base property variable).

You only access the property (through its setter and getter) using the dotted notation [self.myProperty doSomeAction] (or by calling setter / getter explicitly as [[self myProperty] doSomeAction] , which is the exact equivalent, since this is what the compiler translates to when compiling the code)

So, when you write [myProperty doSomeAction] , since it directly accesses the variable - unlike [self.myProperty doSomeAction] , which calls getter from myProperty , thereby making an additional method call / send message - then yes in theory it will be faster than you will receive one sending messages.

But in practice, you will not see any improvement, so there is no need to consider accessing the variable directly (and this will make you free flexibility if you want to implement it in another way later)

---

In addition, if you use modern Runtime (if you are encoding any version of iOS, the obsolete Runtime is used only in 32-bit Mac OSX), then explicitly not specifying a reference variable for the property is no longer required. That way, you can declare @property in .h and @synthesize it in .m without any instance variable (the compiler will generate it for you at compile time), and in that case you cannot call the (non-existent) instance variable! (at least not up to the @synthesize directive)

Answer 3

Using Objective-C 2.0 dot syntax is equivalent to calling getter, so the first snippet will be slower based on the fact that you will carry two more dynamic dispatches.

In this case, the loss will be insignificant, and, obviously, you will get the flexibility that you can change the setter and getter to a later date (for example, if you eventually make this value implicit so that it is not technically stored in memory or pass it to the third object or to do something asynchronous for storage, which may require locking on the getter in some cases).

Answer 4

Slower, as at another step in the work? Yes. Slow, how noticeably or realistically slower? Absolutely not.

You must remember that modern cpus launchers work with several million operations per second. In almost all languages, calling a getter method is essentially the same speed as accessing ivar itself (especially when there is no other code in the getter method).

It’s a good habit to use getters instead of directly accessing Ivars, so I wouldn’t “speed up the process” by ignoring them.

Answer 5

Yes, it would be a little faster, but it is unlikely that you would significantly improve performance by performing such micro-optimization. If you use self.myProperty , you may later decide to use a different access method without changing your code everywhere.