Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Virtual functions are very efficient. Assuming 32 bit pointers the memory layout is approximately:</p> <pre><code>classptr -&gt; [vtable:4][classdata:x] vtable -&gt; [first:4][second:4][third:4][fourth:4][...] first -&gt; [code:x] second -&gt; [code:x] ... </code></pre> <p>The classptr points to memory that is typically on the heap, occasionally on the stack, and starts with a four byte pointer to the vtable for that class. But the important thing to remember is the vtable itself is not allocated memory. It's a static resource and all objects of the same class type will point to the exactly the same memory location for their vtable array. Calling on different instances won't pull different memory locations into L2 cache.</p> <p>This <a href="http://msdn.microsoft.com/en-us/magazine/cc301398.aspx" rel="noreferrer">example from msdn</a> shows the vtable for class A with virtual func1, func2, and func3. Nothing more than 12 bytes. There is a good chance the vtables of different classes will also be physically adjacent in the compiled library (you'll want to verify this is you're especially concerned) which could increase cache efficiency microscopically.</p> <pre><code>CONST SEGMENT ??_7A@@6B@ DD FLAT:?func1@A@@UAEXXZ DD FLAT:?func2@A@@UAEXXZ DD FLAT:?func3@A@@UAEXXZ CONST ENDS </code></pre> <p>The other performance concern would be instruction overhead of calling through a vtable function. This is also very efficient. Nearly identical to calling a non-virtual function. Again from the <a href="http://msdn.microsoft.com/en-us/magazine/cc301398.aspx" rel="noreferrer">example from msdn</a>:</p> <pre><code>; A* pa; ; pa-&gt;func3(); mov eax, DWORD PTR _pa$[ebp] mov edx, DWORD PTR [eax] mov ecx, DWORD PTR _pa$[ebp] call DWORD PTR [edx+8] </code></pre> <p>In this example ebp, the stack frame base pointer, has the variable <code>A* pa</code> at zero offset. The register eax is loaded with the value at location [ebp], so it has the A*, and edx is loaded with the value at location [eax], so it has class A vtable. Then ecx is loaded with [ebp], because ecx represents "this" it now holds the A*, and finally the call is made to the value at location [edx+8] which is the third function address in the vtable.</p> <p>If this function call was not virtual the mov eax and mov edx would not be needed, but the difference in performance would be immeasurably small.</p>
    singulars
    1. This table or related slice is empty.
    1. POAI Applications in C++: How costly are virtual functions? What are the possible optimizations?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USloudej
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POAI Applications in C++: How costly are virtual functions? What are the possible optimizations?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CONice example. Does anyone else get itchy from the redundant memory hit right before the call when a mov ecx, eax would do it?
      singulars
      1. PO
      1. USplinth
    2. COOn a modern CPU the movs might be completely pipelined away.
      singulars
      1. PO
      1. USJimmy J
    3. COIt's important to note that while the instruction overhead of calling a virtual function is minimal that they can negatively affect performance in other ways. For one thing they prevent many optimizations such as inlining and branch prediction. For another they can harm I-Cache performance
      singulars
      1. PO
      1. USAndrew Grant
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload