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
