About the asm code presented above:

I dont know what compiler produced those results, but the this pointer should be passed in the ecx register, not on the stack.

Thus, if the eax register contains ''b'', then push eax is replaced by mov ecx,eax

Of course the compiler would probably have put ''b'' in the ecx register in the first place (usually through a lea instruction).

quote:Original post by Anonymous Poster
About the asm code presented above:

I dont know what compiler produced those results, but the this pointer should be passed in the ecx register, not on the stack.

That''s assuming use of the MS thiscall calling convention, which is the MS default calling convention for member functions. The assembly output was created with Borland bcc32 version 5.4, which uses cdecl by default. However, whether arguments are passed on the stack or via registers is irrelevant. Whatever calling convention is used doesn''t change the fact that there is an additional instruction and a double indirection over the expense of a non-virtual function call.

And that''s just the basal level overhead. Additionally each of the indirection has an increased chance of causing a cache miss. The first indirection increases the probability of a cache miss with the number and size of the vtables referenced in a given working set. The second indirection increases probability of a cache miss as the number of separate called functions and the length of each called functions increases.

However, the cache miss penalty of the second indirection can be ignored, as this is the performance penalty for exploiting polymorphism, not a penalty inherent to the calling convention. So it''s the first indirection that needs to be examined to determine if the virtual call is worth it. So if your benchmark is currently just performing 10,000 virtual function calls off the same pointer, it will probably look a little more grim if you try performing 10,000 virtual function calls off of twenty pointers each to different derived classes, even if none of derived classes override the original base function.

Magmai Kai Holmlor -- it''s the same memory & call dereference when you do base->func() as when you do derived->func(), or even use a local copy of the derived: derive.func().

null_pointer - sorry, forgot to login! Yeah, I neglected that because I almost never use inline functions, but you''re both right. If you''re using a non-dereferenced object, then yeah most modern compilers can inline that.

derived.func(); // probably inlined
derived->func(); // depends; probably NOT (becuase it''s hard to say if another class is derived from this one)
base->func(); // can''t inline, period



David