Alexander Larsson <al...@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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list