Faster Virtual Method Dispatch

Hasan Aljudy hasan.aljudy at gmail.com
Sun Apr 23 14:23:35 PDT 2006


I'm far from being an expert .. but I thought vtable lookups involve two 
  or three jump/call instructions at the assembly level; at least that's 
the impression I got from stepping through code in the VC++ debugger.

Craig Black wrote:
> Most programmers do not realize the overhead involved with calling a method 
> virtually.  A virtual method call is an O(1) operation.  Just  a vtable 
> lookup and a invoking a function pointer.  However, we must also consider 
> that the CPU has no way of performing branch prediction with vtable lookups, 
> so the pipeline is trashed.  Thus, virtual method calls incur a large 
> performance pentalty.
> 
> Interestly, I found that one of the MSVC++ 2005 compiler's profile guided 
> optimizations is replacing the vtable lookup with if statements for the most 
> commonly called virtual methods followed by the vtable lookup, so that 
> branch prediction can be performed in the majority of cases.
> 
> I do not consider myself an expert in the area of compiler optimization, but 
> knowing the little that I do know I have come up with a simple approach that 
> may improve performance.  This approach is described below.
> 
> Performing a binary search using if statements, and then invoking the 
> methods directly rather than using fuction pointers would allow the method 
> dispatch to take advantage of pipelining.  Algorithmically, however, this is 
> no longer O(1), but O(log n), which is bad.  So I would assume that it would 
> only be faster if n (or the number of methods in the vtable) is lower than a 
> given threshold.  This threshold would be determined by testing and would 
> perhaps be different on different processors.  Thus, in order to ensure that 
> this approach is always faster, a relatively low number should be used.
> 
> Like I said I'm not an expert when it comes to low-level optimization 
> strategies.  I don't know how well such an algorithm would work in practice. 
> Comments are obviously welcome.
> 
> -Craig 
> 
> 



More information about the Digitalmars-d mailing list