Allow per-derived class vtable + callbacks for initialization
@mpiechotka
Submitted by Maciej Marcin Piechotka Link to original bug (#706998)
Description
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