GNOME Bugzilla – Bug 706998
Allow per-derived class vtable + callbacks for initialization
Last modified: 2018-05-24 15:38:58 UTC
Currently the vtable is per derived class which means that if there are classes A <- B <- C <- D and A implements interfaces there is one global vtable. That causes problems with bug #706712 as it requires per-class vtable (separate for A, B, C, D) in a way that A can fill it after A vtable is initiaialized fully. = Why is it problem? The speed is a problem. Currently calling an interface function by GObject which is virtual in implementation costs 2-3 pointer indirections which can be quite expensive (Microbenchmark for pointers[1] and indirectly for usage in loop[2]). Implementing the direct lookup in vtable from Vala might further improve the vfunction in loop case. If the vtable for interface would be per-derived class it could be filled with a pointer directly to class function so the A vtable does not need to be considered. = Does it impact real world? Yes. Slowdowns in bug #704754 are nearly exclusivly due to additional 1-2 pointer indirection. = Why not make B, C and D simply implementing interface on Vala side automatically? Because it would break the API and ABI. If there was E class deriving from D it would only override the A vtable and expect functions to work. But interface vtable would point directly to D. [1] http://blog.piechotka.com.pl/2013/05/18/vala-abi-and-branch-prediction/ [2] bug #645850 comment #7
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/751.