Some performance questions

[Chris Nicholson-Sauls]

Lars Kyllingstad wrote:
> Daniel Keep wrote:
>>
>> Lars Kyllingstad wrote:
>>> [snip]
>>> From a performance
>>> perspective, however, it carries with it the overhead of an extra
>>> function call, which I'm not sure I want.
>>>
>>> -Lars
>>
>> You're worried about a second function call which could potentially be
>> inlined, yet you're seemingly not worried about the overhead of virtual
>> calls or heap allocations...
> 
> But that's the problem, you see. I don't know how expensive these 
> operations are, hence my initial question(s). (This was also why I 
> posted my question in D.learn.)
> 
> For instance, I didn't know (not sure I still do) what the cost is of 
> frequent allocation/deallocation/access of stack memory vs. infrequent 
> allocation/deallocation and frequent access of heap memory. From the 
> replies I've got, it seems heap variables make for significantly slower 
> code.

Allocating stack memory is very cheap, because essentially the only 
thing that has to be done is to offset a stack pointer.  Some stack 
variables are even optimized away if only used as temporaries (that is, 
their value is retained in a register until it isn't needed) and for 
short durations.

Allocating heap memory, on the other hand, is expensive for two reasons. 
  The first, is that the heap may have to grow, which means negotiating 
more memory from the operating system, which means switching the CPU 
back and forth between modes, sometimes several iterations.  Of course, 
this doesn't happen on every allocation, or even very often if you're 
careful.  The second reason, is that before every allocation the garbage 
collector will perform a collection run.  This can actually be disabled 
(at least in theory) if you plan on doing several allocations in a short 
period of time, and thereafter re-enabled.

For the latter case, see Phobos 'std.gc' or Tango 'tango.core.Memory'.

Once you have memory allocated, the cost of access is generally about 
the same, except that the stack is more likely to be cached by the CPU. 
  (Since it is inevitably accessed often.)

> Nor was I sure, as you pointed out, how expensive a virtual function 
> call is vs. an extra non-virtual function call.

It adds an additional step.  You start with an index into the object's 
vtable (a list of pointers) rather than the function's actual address. 
Its essentially the same as the difference between assigning to an 
'int**' versus an 'int*'.

> I'm a physicist, not a computer scientist. :)
> 

Which is a good thing, since D could use more experience from 
non-programmers who need to program.  That's a demographic that 
occasionally (but never completely!) gets forgotten.  I'm not exactly a 
thirty-years guru, myself.

-- Chris Nicholson-Sauls