Worth it for an object to caching its own IMPs?

[izidor.jerebic at siol.net (Izidor Jerebic)]

On Feb 29, 2004, at 8:50 AM, Scott Stevenson wrote:

> Is it worth it (or even possible) for an object to cache method 
> implementations of itself? And if so where is the best place to do it?
>
> For example, is this a good idea:
>
> - (id)init
> {
>     if (self = [super init])
>     {
>         someSelector        = @selector(someMethod:);
>         someImplmentation   = [self methodForSelector: someSelector];
>     }
>     return self;
> }
>

Yes, this should do nicely...

  Except if these methods are get/set accessors and are used in 
key-value observing, because in automatic observing there are some 
run-time peculiarities and KVO may not work correctly.

Remember that caching is supposed to be used only in very tight loops. 
All other cases are probably not worth it, since objc runtime is very 
efficient in dispatching methods. As always, you should profile before 
doing optimizations...

>
> I'm in a situation where an object is calling methods on itself 
> frequently and latency is important. I've considered dropping down to 
> CF, but this seems like a good compromise. All the examples of IMP 
> caching I've seen up to this point involve getting the addresses of 
> methods for objects other than 'self'.
>
>
The caching must always be done by the code of the sender of the 
message (caller of the function), since at that point in code you must 
replace [obj someMethod:arg] with someMethodImp( obj, 
@selector(someMethod:), arg ). If the sender and receiver are the same 
object, naturally the receiver will also do the cacheing, because it is 
the sender :-)

izidor