Allocation overhead, reference counting overhead, loss of locality of reference, and there's simply no good reason to do it. (Unless there is one. But that's a case by case issue.)
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
I see. One more question: What exactly does allocation overhead mean?
It means all the wasted memory and time that comes from dynamically allocating something on the heap. You need space to store the pointer to the object. The runtime library needs space to store heap management information. And the runtime needs time to find a free spot on the heap and update the management information.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Thanks. Until now I never though about wasting time using dynamical allocation.
I'm going totally off-topic now, but I find this to interesting..
So I guess the heap management and allocation algorithm is OS dependent? And is the allocation time constant or can it be expressed as depended from any parameters, maybe the fragmentation rate?
And what always wonders me: why is stack so fast? look at that little example:
does the process stack work that way? if so, I guess the compiler can optimize a lot, the last pop and push b for example and push/pop are also very fast operations (1 clock tick each, right?). but for a lot of global and automatic variables, doesn't this become slow? maybe even slower than dynamic allocation? And where do all the pop'ed values go, if the cpu runs out of registers? for example if I read an vector element hidden deep in the stack?Code:int main() { int a; // push a int b; // push b printf(%i, a); // pop b, pop a, print a, push a, push b printf(%i,b); // pop b, print b, push b }
I guess it just doesn't work that way.
OS dependent and runtime library dependent. MinGW's C library might well have a different algorithm than the MS CRT.
Depends on the algorithm. Most will probably be slower when there's bad fragmentation.And is the allocation time constant or can it be expressed as depended from any parameters, maybe the fragmentation rate?
Perhaps push. Perhaps just registers. Perhaps - most likely - just an increase in the stack pointer.Code:int a; // push a int b; // push b
Oh no, not at all. This is a function. It's more like, push string address, push a, call printf, reset stack pointer. (No need to pop arguments individually.)Code:printf(%i, a); // pop b, pop a, print a, push a, push b
In fact, the compiler may just leave the string address there, since it's the same as before. Push b, call printf, reset stack pointer.Code:printf(%i,b); // pop b, print b, push b
Close. However, the process stack allows direct access to elements not on the top. It's after all just memory. No need to pop anything off to access an element further down; just read at an offset from the stack pointer.does the process stack work that way?
An enormous lot. You can tell your compiler to write out the assembly it generates. It can be interesting. Make sure you compile in release mode.if so, I guess the compiler can optimize a lot
No, they're memory accesses. That makes them pretty slow, actually. Although, since the top of the stack is basically always in L1 cache, they're as fast as memory accesses get.push/pop are also very fast operations (1 clock tick each, right?).
No. First, global variables have nothing to do with the stack. Also, at worst it's an indirect memory access, to memory that is most likely in cache. (Unlike some heap memory lying around somewhere in the huge expanses of memory. Those are only in the cache if they were recently used.)but for a lot of global and automatic variables, doesn't this become slow? maybe even slower than dynamic allocation?
As I said, no need to pop.And where do all the pop'ed values go, if the cpu runs out of registers? for example if I read an vector element hidden deep in the stack?
You should study computer architecture a bit.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Actually it more likely pushes "a" first, then the string. But that doesn't matter really. Also, there's no reason it has to even pop the arguments after the function call. Many compilers will allow quite a few function call parameters to build up on the stack then pop them all at once. Called "deferred pop."
Actually, the order of argument pushing [if arguments are pushed at all] is dependant on the compiler you are using, and the settings[1], so there's no guarantee which is pushed first or last. Many compilers also allow passing args in registers. It is quite "normal" to push the arguments "right to left", but there's absolutely no guarantee that this is how the compiler does things.
[1] printf() and other variable parameter functions are sort of exceptional in this case, because it becomes very difficult to find out where the "last fixed argument" (format string in printf's case) is on the stack if you don't push the fixed args last.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.