Re: objective-c: how slow ?

[Marko Mikulicic]

Malmberg wrote:

>
> Inline caches are a bad idea because:
> 1. They would make the code larger.

Perhaps only compile some methods with IC through a compiler flag
could help where hard coded IMPs are not well suited, and still
save code where they are not needed.

> 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 ?

> 3. Modifying the code means shared libraries can't be shared between
> programs. This is a problem with the other cache-systems as well, but
> that could be solved (at the loss of speed) by an extra level of
> indirection.

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.
  On systems which support copy-on-write pages, IC are possible at the cost of
some memory. In contrast to C++ the pages must not be updated at load time by
the dynamic linker so startup time is not effected by this.

Marko Mikulicic