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 al...@redhat.com alexander.lars...@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! _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list