Last time round, we looked at the way an unnamed developer had used Cocoa routines to chop up a simple C-string in order to determine whether or not it contained a particular, named OpenGL extension name.

A few folks pointed out that if, hypothetically speaking, some new extension name gets devised that happens to be a superstring of the extension name we're after, my simple strstr solution would break. Absolutely right, but this rather missed the point of the discussion which was a focus on writing efficient code in Cocoa and using the right tools for the job.

This time, I want to dig a little deeper by looking at the code generated by gcc in response to your carefully crafted Objective-C code. I'm hoping to demonstrate that you will often get more than you bargained for.

To begin with, consider a simple method invocation such as:

NSCursor * cursor = [NSCursor crosshairCursor];

This returns an instance of the cross-hair cursor. On an Intel machine, this will generate the code shown below.

Listing One

00001e60 movl        0x0000501c,%eax              crosshairCursor
00001e65 movl        %eax,0x04(%esp,1)
00001e69 movl        0x0000502c,%eax              NSCursor
00001e6e movl        %eax,(%esp,1)
00001e71 calll       _objc_msgSend

The objc_msgSend routine lies at the heart of Objective-C message dispatching. The first parameter it takes is effectively a pointer to the NSCursor class since we're calling a class method rather than instance method. The second parameter is the selector for the crosshairCursor method. Contrary to what some folks think, there is nothing remotely magical about selectors. A selector is simply a pointer to a good old-fashioned C string containing the selector name. After the call to objc_msgSend, the EAX register will contain the wanted NSCursor instance.

The Objective-C message dispatcher is reasonably efficient, especially second time around. This is because once it's seen a particular message selector for a particular class; it caches the address of the corresponding method making subsequent lookups more efficient.

Note: If you want to get a better idea of objc_msgSend's workings, and don't mind wading knee-deep through PPC code, see here where ways of speeding up Objective-C dispatching are discussed. The "real" source code is also available as part of OpenDarwin.

Rather than focusing on execution speed, I want to look here at the size of generated code. In Listing One, we've eaten up 22 bytes in making that method call. Not a big deal you might say, and you'd be right. But it amazes me how often I see code that looks like this:

Str1 = [[NSUserDefaults standardUserDefaults] stringForKey: @"myStr"];
Int1 = [[NSUserDefaults standardUserDefaults] integerForKey: @"myInt"];
Float1 = [[NSUserDefaults standardUserDefaults] floatForKey: @"myFloat"];
..etc..

This sort of code pattern is so ubiquitous in Cocoa programming that I expect to be universally criticised for criticising it. But I ask you: what's the point in spending another 22 bytes of code to retrieve the same NSUserDefaults object that was being used on the previous line? Do Cocoa developers believe that there's something inherently volatile about these shared globals? After all, beneath the covers, [NSUserDefaults standardUserDefaults] is doing nothing more than providing thread-safe access within the AppKit library.

If you've got a complex application that needs to initialise a whole slew of user preferences, you can easily chew up several hundred bytes with repeated calls to retrieve the shared defaults object. Personally, I'd make the call once, store the NSUserDefaults object in a local variable, and then use that inside my initialisation routine.

Of course, the nay-sayers will complain, "But we've always done it that way", "I've got a quad-core development machine", "Who cares about a few hundred extra bytes?", yada, yada, yada. That's fine. Presumably, those same folks sprinkle their code liberally with gratuitous calls to the sleep library routine just to make sure things don't execute too quickly, and lots of extra malloc calls just to use up that surplus memory, right?

Moving swiftly on, take a look at the seemingly innocent line of code below:

NSRect insetRect = NSInsetRect ([self frame], 2.0, 2.0);

The gcc compiler absolutely loves rectangles, or any data structure for that matter. Once you give it an NSRect to play with, it just doesn't want to let go. Listing Two shows how that one-liner balloons out into 147 bytes of code.

Listing Two

00002902  movl        0x08(%ebp),%ecx
00002905  leal        0x00002754(%ebx),%eax        frame
0000290b  movl        (%eax),%eax
0000290d  leal        0xb8(%ebp),%edx
00002910  movl        %eax,0x08(%esp,1)
00002914  movl        %ecx,0x04(%esp,1)
00002918  movl        %edx,(%esp,1)              
0000291b  calll       _objc_msgSend_stret
00002920  subl        $0x04,%esp
00002923  movl        0xb8(%ebp),%eax
00002926  movl        %eax,0xe8(%ebp)
00002929  movl        0xbc(%ebp),%eax
0000292c  movl        %eax,0xec(%ebp)
0000292f  movl        0xc0(%ebp),%eax
00002932  movl        %eax,0xf0(%ebp)
00002935  movl        0xc4(%ebp),%eax
00002938  movl        %eax,0xf4(%ebp)
0000293b  leal        0xa8(%ebp),%edx
0000293e  leal        0x00000728(%ebx),%eax
00002944  movl        (%eax),%eax
00002946  movl        %eax,0x18(%esp,1)
0000294a  leal        0x00000728(%ebx),%eax
00002950  movl        (%eax),%eax
00002952  movl        %eax,0x14(%esp,1)
00002956  movl        0xe8(%ebp),%eax
00002959  movl        %eax,0x04(%esp,1)
0000295d  movl        0xec(%ebp),%eax
00002960  movl        %eax,0x08(%esp,1)
00002964  movl        0xf0(%ebp),%eax
00002967  movl        %eax,0x0c(%esp,1)
0000296b  movl        0xf4(%ebp),%eax
0000296e  movl        %eax,0x10(%esp,1)
00002972  movl        %edx,(%esp,1)
00002975  calll       _NSInsetRect
0000297a  subl        $0x04,%esp
0000297d  movl        0xa8(%ebp),%eax
00002980  movl        %eax,0xd0(%ebp)
00002983  movl        0xac(%ebp),%eax
00002986  movl        %eax,0xd4(%ebp)
00002989  movl        0xb0(%ebp),%eax
0000298c  movl        %eax,0xd8(%ebp)
0000298f  movl        0xb4(%ebp),%eax
00002992  movl        %eax,0xdc(%ebp)

There are a few things to explain in the code listing above, which I'll highlight by referring to a hex address. To begin with, Cocoa methods such as [NSView frame] and the non-OOP NSInsetRect routine appear to return a structure as the function result. In fact, they don't. Instead, under the hood, they pass a hidden pointer argument ($2918 and $2972) which is used by the called routine to store the returned structure, a NSRect in this case.

This would be ok if gcc behaved itself, but – like I said – it loves fooling around with data structures. When the call to [self frame] is made, you may notice ($290D) that the target routine is instructed to place the resulting NSRect into the "quartet" of implicit local variables at offsets $B8/$BC/$C0/$C4. However, once the call is made, the rectangle is immediately copied out of these four memory locations ($2923) into another quartet at $E8/EC/F0/F4. Why? Why not just pass the offset of the second quartet to [self frame] in the first place?

The rectangle then gets copied again (!) when it's moved onto the stack prior to the call to NSInsetRect ($2956). Finally, after the call to NSInsetRect, the resulting inset rectangle is moved from the local variables at $A8/$AC/$B0/$B4 to $D0/$D4/D8/$DC.

You're probably thinking that I'm cheating here; surely gcc doesn't really generate that much code, does it? Ok, I am cheating – a little. Listing Two was created with compiler optimisation turned off – it's the setting you'd get when using the Debug configuration under XCode. If you switch to the Release configuration and rebuild, the above code snippet will shrink to 118 bytes, which is better, but definitely not awesome. The compiler still insists on having NSRect-returning routines place the returned function result in one place, and then pointlessly copy it some place else. But at least with optimisation turned on, the compiler is smart enough to use the esi, ebx, ecx and edx registers as an intermediate store for the four rectangle fields, thus saving on some memory reads.

Note: Incidentally, you'd be surprised just how many commercial applications are released using the Debug configuration. The majority of apps that I've peeked inside show the same sloppy code generation as is typified in Listing Two.

What's the bottom line here? The biggest obstacle to runtime efficiency is that we're passing around the rectangle by value rather than by reference. As I've mentioned, the routines that return an NSRect do actually use a hidden pointer implementation, but when passing an NSRect to a routine, all 16 bytes are passed on the stack. There are obviously sound reasons for doing things this way, the principal one being that if (for example) you call [NSScreen frame] to retrieve the dimensions of a screen, you really don't want the application getting access to the real data; you must always give a copy of your data to the calling code.

Finally, here's a little teaser for you experienced Cocoa-heads. Going back to Listing One, you may notice that the "self" pointer (either a pointer to an object instance, or to a class if we're dealing with a class method such as [NSCursor crosshairCursor]) is always passed last in the EAX register before the call. Can you figure out why? ®

Related stories

• Making the move to the Mac (21 September 2007)

  https://www.theregister.com/2007/09/21/making_move_mac_2/

• How to counter premature optimisation (22 June 2007)

  https://www.theregister.com/2007/06/22/premature_optimisation/

• Uncle Mac takes A Cup of Cold Cocoa... (29 December 2006)

  https://www.theregister.com/2006/12/29/grumpy_old_man_on_cocoa/

• Exceptional C++ and More Exceptional C++ (26 October 2006)

  https://www.theregister.com/2006/10/26/exceptional_cplusplus_more/

• Out of the (C++) loop (8 August 2006)

  https://www.theregister.com/2006/08/08/cplusplus_loops/