Re: GLib interface call is too slow.

[Kentaro NAKAZAWA <kentaro nakazawa nifty com>]

Alexander Larsson <alexl redhat com> writes:
>
> This is similar to the original report, so I think something weird
> happened with your run.

I did a similar measurement by each version of glib.
(2.24.0, 2.24.1, git master)
However, it was a same result.

----------------
GLib Dispatch Mechanisms
10000000 iterations
Times in seconds

direct:    0.031432
virtual:   0.033165
interface: 1.431950
----------------

Hmm... It is examined why there is a difference. 

>
> Anyway, since the original blog entry some stuff has in fact changed in
> the interface lookup. It now uses a slightly less memory efficient but
> constant time interface lookup instead of a binary search. However, such
> speedups are only visible if your objects implement multiple interfaces,
> as otherwise a seek-over-one-element is just as fast as a constant time
> lookup.
>
> There is one misdesign in glib interfaces, and its that its possible to
> add interfaces to a class at runtime. This forces some threadsafety
> handling on interface lookup which could otherwise be avoided. However,
> with the latest glib (2.24) we use a lockless algorithm for this, so its
> not such a big problem anymore.
>
> It might be possible to make this somewhat faster if you spend some time
> on it, but its not ever gonna be near the virtual call, since a vcall is
> just a few instructions that are very optimized by cpus (its after all
> one of the most common things apps do). 
>
> However, just because interface lookups is 7 times slower than vfunc
> calls does not make them slow. The above loop called 10 million
> interface calls in about half a second. Any normal design is not gonna
> call that many interfaces, so the actual cost of the interface lookup
> compared to other things in your app (like doing real work) is likely
> negligible. So, don't avoid using interfaces just because you're scared
> of the cost. Of course, don't do stupid things like call interfaces in
> the inner loop of some tight code, but that is equally bad with vfuncs
> or even normal functions.
>
> The rule in optimization is as always: measure measure measure measure.
> Don't start with weird micro-optimizations that don't have any affect on
> real performance.

I'm sorry. It is not felt that it slows overall. 
After it measures it more carefully, it reports when there is something. 

-- 
Kentaro NAKAZAWA