why is the stack faster?

[Sharon]

hi all.
why value types which are stored in the stack, give better performance,
than reference types which are stored in the heap?
are not both stored in the ram?
thanks.

[n!]

> why value types which are stored in the stack, give better performance,

than reference types which are stored in the heap?
are not both stored in the ram?

It is quicker to move the stack pointer than it is to allocate memory.
Allocating referenced objects is still fast in managed code, but changing
the stack pointer is still faster. Also taking into account that a method
knows which value types are created internally and thus they all get
allocated at once on entry to the method (or as part of their owning
object).

n!

[Andreas Håkansson]

n!,

Not quite true. The managed heap also uses a pointer to indicate were
the next object should be placed in the heap. Once the object has been
inserted into the heap, the pointer is moved to point after the last object.

However there is another layer of indirection since you will have to go from
stack -> heap before you get the correct object. Also the stack is local for
each thread and is inherintly thread safe, where as the heap is free-for-all
memory (of course for each application) so I would (wouldn't swear my
life on it - perhaps someone can confirm) think there is some kind of
lock mechanism being used to ensure thread safety of the information used
in the heap.

//Andreas

"n!" <nf********@nomailplease.com> skrev i meddelandet
news:O5**************@TK2MSFTNGP09.phx.gbl...

why value types which are stored in the stack, give better performance,
than reference types which are stored in the heap?
are not both stored in the ram?

It is quicker to move the stack pointer than it is to allocate memory.
Allocating referenced objects is still fast in managed code, but changing
the stack pointer is still faster. Also taking into account that a method
knows which value types are created internally and thus they all get
allocated at once on entry to the method (or as part of their owning
object).

n!

[n!]

> Not quite true. The managed heap also uses a pointer to indicate were

the next object should be placed in the heap. Once the object has been
inserted into the heap, the pointer is moved to point after the last object.
However there is another layer of indirection since you will have to go from stack -> heap before you get the correct object. Also the stack is local for each thread and is inherintly thread safe, where as the heap is free-for-all memory (of course for each application) so I would (wouldn't swear my
life on it - perhaps someone can confirm) think there is some kind of
lock mechanism being used to ensure thread safety of the information used
in the heap.

Yes, sorry. This is what I meant by 'allocating referenced objects is still
fast in managed code'. I just assumed there was 'a bit more' to it than
simply moving adjusting the pointer (and ignoring the GC collects that occur
infrequently) :) Unless I'm missing something else too?

Thanks,
n!

[Morten Wennevik]

In fact, allocating memory in managed code can be faster than the
traditional unmanaged way. New objects will always be placed on top (or
bottom if you prefer) of the heap pointer, while the garbage collector
clears memory "holes", rearranges all objects and updates the reference
table pointers.

Happy coding!
Morten Wennevik [C# MVP]

[Brad Williams]

..NET heap allocation is very fast -- but this is usually irrelevant, since
most allocations cause garbage collection activity, and that is the big bad
bottleneck. Short and sweet article here with advice:

http://msdn.microsoft.com/library/en...asp?frame=true

BTW, heap objects are generally not thread safe until you make them thread
safe ... that's the whole point of e.g. lock():

http://msdn.microsoft.com/library/en...asp?frame=true

Brad Williams
"n!" <nf********@nomailplease.com> wrote in message
news:OG**************@TK2MSFTNGP12.phx.gbl...

Not quite true. The managed heap also uses a pointer to indicate were the next object should be placed in the heap. Once the object has been
inserted into the heap, the pointer is moved to point after the last object.

However there is another layer of indirection since you will have to go

from

stack -> heap before you get the correct object. Also the stack is local

for

each thread and is inherintly thread safe, where as the heap is

free-for-all

memory (of course for each application) so I would (wouldn't swear my
life on it - perhaps someone can confirm) think there is some kind of
lock mechanism being used to ensure thread safety of the information used in the heap.

Yes, sorry. This is what I meant by 'allocating referenced objects is

still fast in managed code'. I just assumed there was 'a bit more' to it than
simply moving adjusting the pointer (and ignoring the GC collects that occur infrequently) :) Unless I'm missing something else too?

Thanks,
n!

[Fuzzy]

I would also add that the heap also incurs the possibility of page
faults whereas stack variables should always be in the current page.
Also, the compiler has a better optimization chance of storing values
in processor registers instead of RAM.

[Sharon]

thanks for your help.
as i understand it now, the heap is slower because:
1. the extra way to reach the object.
2. garbage collection activity.
3. value types are compiled to work better with the processor registers.

true?

i also understand that i don't really understand what the stack is.
"Sharon" <ta*******@hotmail.com> wrote in message
news:en**************@tk2msftngp13.phx.gbl...

hi all.
why value types which are stored in the stack, give better performance,
than reference types which are stored in the heap?
are not both stored in the ram?
thanks.