title: Are there any rules of thumb when `virtual` is a considerable overhead?
body: <p>My questions is basically completely stated in the title, however let me elaborate.</p>
  
  <p><strong>Question:</strong>
  Maybe worth of rephrasing, how complicated/simple the <code>virtual</code> method has to be, to make the mechanism a considerable overhead? Are there any rules of thumb for this? E.g. If it takes 10 minutes, uses I/O, complex <code>if</code> statements, memory operations etc. it's not a problem. Or, if you write <code>virtual get_r() { return sqrt( x*x + y*y); };</code> and call it in a loop you will have troubles.</p>
  
  <p>I hope the question is not too general as I seek some general but concrete technical answers. Either its hard/impossible to tell, or virtual calls take so much time/cycles resources, and math takes this, I/O this.</p>
  
  <p>Maybe some technical people know some general numbers to compare or did some analysis and can share general conclusions. Embarassingly I dunno how to make those fancy <code>asm</code> analysis =/.</p>
  
  <p>I would also like to give some rationale behind it, as well as my use-case.</p>
  
  <p>I think I saw more than few questions with people refraining from using virtuals like open fire in the forest during drought, for the sake of performance, and as many individuals asking them "Are you absolutely sure that virtual overhead is really an issue in your case?".</p>
  
  <p>In my recent work I ran into a problem which can be placed at both sides of the river, I believe.</p>
  
  <p>Also bear in mind I do not ask how to improve implementation of interface. I believe I know how to do it. I'm asking if it's possible to tell when to do it, or which to choose right of the bat.</p>
  
  <p><strong>Use-case:</strong></p>
  
  <p>I run some simulations. I have a class which basically provides a run environment. There is a base class, and more than one derived class that define some different workflows. Base collects stuff as common logic and assigning I/O sources and sinks. Derivatives define particular workflows, more or less by implementing <code>RunEnv::run()</code>. I think this is a valid design. Now let's imagine objects that are subjects of the workflow can be put in 2D or 3D plane. The workflows are common/interchangeable in both cases, so the objects we are working on can have common interface, although to very simple methods like <code>Object::get_r()</code>. On top of that lets have some stat logger defined for the environment.</p>
  
  <p>Originally I wanted to provide some code snippets but it ended up with 5 classes and 2-4 methods each i.e. wall of <code>code</code>. I can post it on request but it would lengthen the question to the twice of current size.</p>
  
  <p>Key points are: <code>RunEnv::run()</code> is the main loop. Usually very long (5mins-5h). It provides basic time instrumentation, calls <code>RunEnv::process_iteration()</code> and <code>RunEnv::log_stats()</code>. All are virtual. Rationale is. I can derive the <code>RunEnv</code>, redesign the <code>run()</code> for example for different stop conditions. I can redesign <code>process_iteration()</code>, for example to use multi-threading if I have to process a pool of objects, process them in various ways. Also different workflows will want to log different stats. <code>RunEnv::log_stats()</code> is just a call that outputs already computed interesting stats into a <code>std::ostream</code>. I <em>guess</em> using virtuals and has no real impact.</p>
  
  <p>Now let's say the iteration works by calculating distance of objects to the origin. So we have as interface <code>double Obj::get_r();</code>. <code>Obj</code> are implementation for 2D and 3D cases. The getter is in both cases a simple math with 2-3 multiplications and additions.</p>
  
  <p>I also experimented in different memory handling. E.g. sometimes coordinate data was stored in private variables and sometimes in shared pool, so even the <code>get_x()</code> could be made virtual with implementation <code>get_x(){return x;};</code> or <code>get_x(){ return pool[my_num*dim+x_offset]; };</code>. Imagine calculating something with <code>get_r(){ sqrt(get_x()*get_x() + get_y()*get_y()) ;};</code>. I suspect virtuality here would kill performance.</p>