Re: objective-c: how slow ?

[Erik M. Buck]

> you would modify the compiler so that instead of compiling
>
>  [receiver message];
>
> into
>
>  {
>    IMP __imp = objc_msg_lookup(receiver, @selector(message));
>    __imp (receiver, @selector(message));
>  }
>
> it would compile it into
>
>  {
>    static Class __class = Nil;
>    static IMP __imp = NULL;
>
>    if (receiver->isa != __class)
>      {
>         __class = receiver->isa;
>         __imp = objc_msg_lookup(receiver, @selector(message));
>      }
>
>    __imp (receiver, @selector(message));
>  }
>
> it's a rough sketch, but I suppose something like this might actually
> work! :-)
>

As you know, the above is not thread safe.  Furthermore, the above is likely
SLOWER.  The variable assignments require memory writes.  The use of static
variables probably means the memory will not be in the cache.  The
comparison and branch is almost as expensive as the function call, and for
the common case when the IMP for @selector(message) is in receiver's method
cache, you are getting effectively the same optimization.  I doubt there is
ANY benefit to the above code.  It probably will make things slower.  It is
not thread safe.  It requires more memory and more code.  It abuses
processor memory cache.  It substantially duplicates what is already
happening in objc_msg_send.

Given:
>  {
>    IMP __imp = objc_msg_lookup(receiver, @selector(message));
>    __imp (receiver, @selector(message));
>  }

One optimization would be to inline objc_msg_lookup()
Another optimization would be to use jmp rather than a function call to
execute the IMP.  The NeXTstep runtime diddles the stack and jumps to the
IMP.  It is slightly faster, but it is assembly language and therefore less
portable.


Finally, as you point out, when optimization is critical, the programmer can
call the IMP directly.