Some performance questions

[Lars Kyllingstad]

Chris Nicholson-Sauls wrote:
> 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

Thank you for a very informative reply. :)

-Lars