Comments on: objc_msgSend

by: Daniel Jalkut

Mon, 01 Aug 2005 12:12:14 +0000

How does this hack compare with the objc_msgSend_rtp optimization included in Tiger? It sounds like essentially the same approach (but presumably Apple’s sanctioned technique doesn’t have the same drawbacks as your compiler mod).

I assume your performance comparisons are against plain 10.4 compiles. Have you profiled your code compiled on 10.4 with “-fobjc-direct-dispatch” option set?

Daniel

by: ridiculous_fish

Mon, 01 Aug 2005 12:59:46 +0000

Here’s the skinny on -fobjc-direct-dispatch:

The general theory of “remove the stub overhead” is the same. The implementation is different, and has different tradeoffs. The above approach relies on the dynamic linker to supply the address of objc_msgSend() at runtime, stashes that in a fast place, and calls objc_msgSend() through the function pointer. -fobjc-direct-dispatch relies on the dynamic linker to put the objc_msgSend() implementation at a fixed address known by the *static* linker (or possibly the compiler), so the function can be jumped to directly, without the overhead of the function pointer.

-fobjc-direct-dispatch is definitely faster, about 17% faster than the approach I outlined above.

-fobjc-direct-dispatch requires fancy linker support to always put the objc_msgSend_rtp() function at the same address. In this way, it’s a bit like a hybrid static/dynamic linking. The above approach does not require modifying the linker.

In principle, -fobjc-direct-dispatch is dangerous because the address is hardwired. If the objc_msgSend_rtp() function needs to move (because it grows too big, for example), programs would have to be recompiled to pick up the new implementation. The above approach does not have that problem. (In pratice, objc_msgSend() is quite stable, so that is unlikely to be a concern.)

The biggest practical concern is that programs built with -fobjc-direct-dispatch will not run on pre-Tiger systems; the fancy linker support is missing. The above approach should be able to run on pre-Tiger systems.

by: Daniel Jalkut

Mon, 01 Aug 2005 13:01:28 +0000

Thanks for that detailed explanation!

by: Ross

Mon, 01 Aug 2005 13:49:30 +0000

Did you not use qsort because worst case it is O(n**2)?

I am guessing but I *SO* want that pen (I have a pen habit to support).

by: Mark Rowe

Mon, 01 Aug 2005 14:24:10 +0000

A bit of a guess: one reason not to use the standard library’s qsort is that it adds an extra function call via a function pointer for each comparison.

by: Dan V. P. Christiansen

Mon, 01 Aug 2005 15:21:38 +0000

I’d say the same thing as Mark Rowe, with the addition that the call to qsort is indirect, it seems, and my guess is that would mean that the call to your comparison function becomes indirect as well, defeating the purpose of your test.

by: Mark Rowe

Mon, 01 Aug 2005 17:05:01 +0000

Dan, that’s what I was getting at. Thanks for following the train of thought through to it’s conclusion. :)

by: Out of Cheese

Mon, 01 Aug 2005 20:32:24 +0000

Objective-C messaging

Peter has some interesting thoughts about objc_msgSend. His post is worth reading if you’re curious about some complicated ways to...

by: Duncan mak

Tue, 02 Aug 2005 00:21:02 +0000

This is interesting:

http://www.cincomsmalltalk.com/userblogs/vbykov/blogView?showComments=true&entry=3300398515

by: Erik M. Buck

Tue, 02 Aug 2005 06:54:29 +0000

There is a lot of related information at http://www.mulle-kybernetik.com/artikel/Optimization/

In particular, there are interesting ideas for optimizing objc_msgSend() at http://www.mulle-kybernetik.com/artikel/Optimization/opti-9.html