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

On Tue, Feb 3, 2009 at 3:44 PM, Chris Nicholson-Sauls <ibisbasenji@gmail.com> wrote:
> 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.

It should be "before every allocation the garbage collector *may* perform a collection run."  If it collected on every allocation it would make your program's execution speed next to useless ;)

Jarrett Billingsley wrote:
> On Tue, Feb 3, 2009 at 3:44 PM, Chris Nicholson-Sauls
> <ibisbasenji@gmail.com> wrote:
>> 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.
> 
> It should be "before every allocation the garbage collector *may*
> perform a collection run."  If it collected on every allocation it
> would make your program's execution speed next to useless ;)

Well okay, yes, it *may*.  I was in a hurry and trying to be general. ;)  Chances are, though, that if you are doing so many allocations in a short period as to be worried about it, that it probably will.  If I remember right, the current GC runs a collection just before requesting more heap, so its actually related to the first issue.  (I may well remember wrong, its been a very long time since I dove into the GC code.)

-- Chris Nicholson-Sauls