> On May 21, 2015, at 9:28 AM, Alex Zavatone <z...@mac.com> wrote: > > @synthesize thing = _thing; > Which makes the internal and private ivar to be _thing while the property > becomes thing. > In my case, this helps to uncover where the original code is accessing the > ivar as opposed to the property.
I always use this naming convention. Not just for the reason you state, but because it makes it obvious which variables are ivars, i.e. which have object scope and which have local scope. (Yeah, you can make Xcode color them differently, but it’s not as obvious.) I highly recommend it. > Now that I have a path forward and understand why things are what they are, > this brings up the wonderful speed issue of "how much slower is property > access vs ivar access”. Yeah, I think we’ve had some vigorous debates about this topic in the past. And it’s not just about clock cycles, it’s also about code size — that blog post you linked to shows that ivar access is less than half as many instructions, plus the value can be saved in a register and reused. Code size significantly affects performance because of CPU’s limited instruction cache sizes. In most high level app code it probably doesn’t make much of a difference. Me, I tend to write lower-level code that does things like data storage and database queries, which are often seriously CPU-bound and where shaving off CPU cycles wherever possible does produce real improvements. (Plus, I’m lazy and it’s faster to type “_foo” than “self.foo”.) —Jens _______________________________________________ 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
