Re: GLib interface call is too slow.

[Alexander Larsson <alexl redhat com>]

On Tue, 2010-06-15 at 02:17 +0900, Kentaro NAKAZAWA wrote:
> Hello.
> (sorry, my English is not so good ;)
> 
> I am using the Vala language with Fedora 13.
> 
> http://samdanielson.com/2009/9/8/glib-interface-performance-with-vala
> 
> The interface performance is tested on the above site.
> 
> My test is almost same result with GLib 2.22. (seven times slower)
> 
> The following resulted when a similar test was done with GLib 2.24.
> 
> ----------------
> GLib Dispatch Mechanisms
> 10000000 iterations
> Times in seconds
> 
> direct:    0.000004
> virtual:   0.037149
> interface: 1.388864
> ----------------
> 
> Oops! 37 times slower.

I don't get that with latest glib (git master but should be similar to
2.24 in this respect):

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

direct:    0.053636
virtual:   0.090394
interface: 0.653274
-----------------------

This is similar to the original report, so I think something weird
happened with your run.

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.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a genetically engineered pirate hairdresser searching for his wife's true 
killer. She's a tortured goth mercenary with the power to bend men's minds. 
They fight crime!