Re: objective-c: how slow ?

[Malmberg]

>  > 2. They're hard to do in a thread-safe way without locking (probably
>  > impossible).
> 
> Deferred update is not possible because maintaing call statistics
> is a performance bottleneck in objc, so I guess that IC are not feasible
> in objc in a thread safe way. Any other ideas ?

Well, if you really _really_ need the extra 4-5 cycles/call, how about
adding a runtime function objc_need_more_speed(@selector(foo: bar:
zot:),[SomeClass class],[SomeOtherClass class],...,NULL);. It would
generate an 'outline' stub (style 2) with those classes and change the
sarray entries for the selector in those classes to point to a function
that patches the caller to directly call the stub. You could even add an
argument that controls whether the stub should bother to correctly
handle a nil receiver or not (if you can guarantee that you'll never
call that selector with a nil receiver you can gain ~1 cycle/call).
There are a few practical problems, but I think it could be done.

Theoretically, there's recompilation.

I had a look at some of the PIC-papers, and it seems their target is
quite different from ours. As far as I can tell, they put a direct call
at ~200ns and a normal lookup at ~15000ns (~75 times slower). With the
optimized obj-c lookup, a direct call takes ~27.5ns, and a lookup
~47.5ns (1.7 times slower).

> How are C++ virtual calls handled in shared libraries ?
> I've heard that the biggest performance problem in the startup
> of a KDE app is copy-on-write of virtual pointer tables contained
> in shared libraries. They must be updated because the shared libraries can
> be mapped at different addresses.

I suppose so, though I've never looked at how that's done. I'll see if I
can find the code responsible for this.

- Alexander Malmberg