The stack, when it comes to C#, is an implementation detail. It's a thing the JIT'ter uses to optimize your code and not much more.

There are some hard and fast ( and wrong ) rules about what goes on the stack, but more specifically the rules are actually what doesn't go on the stack. Namingly reference types and classes.

Value types *may* be created on the stack, as may structs, but there is actually no promise this will happen.


As to the super simple stupid explanation.


Ever been to a cafeteria where the plates are all stacked and when you go through the buffet you grab the top one? Well essentially that is what a stack is in C#. It's a chunk of memory that is set aside for ( the JIT engine to ) optimize access to certain types of variables. One of the advantages of a stack is, you know exactly where everything is, so there are no spaces and gaps and since we are dealing with value types, no unpredictability about when they will expire. This essentially means no garbage collection and very predictable locations, so no performance loss to searching or garbage collecting. This means, generally, the stack is always fastest.


Always fastest, but not always faster. Theoretically the heap can be just as fast, it all really depends on what goes on with memory. In the case of heap, instead of a stack, think of it like a giant array. As you allocate memory, "cells" of that array are used up. Eventually you use up all memory and one of two things occurs, the array is grown or garbage collection occurs, possibly both. Now as you are filling this array with memory, your performance is pretty much the same as the stack, as you are generally assigning your memory to the next top most location available.

Thing is, in time, just like your computer hardrive, this memory gets fragmented. So while the heap is continuous to start ( and therefore performing comparable to the stack ), as you allocate and free memory "holes" in the continuous array of memory locations essentially become available, so new allocations re-use old locations, or possibly are split into various different locations that have been made available. Now, when accessing your memory, you essentially don't have just a straight lookup any more, you may have multiple lookups and a search involved. Once this happens, the performance advantage of the stack becomes obvious.


Of course, as Eric Lippert said, this is all an implementation detail. You as the developer have absolutely no real control over what happens, beyond know what times explicitly will NOT be created on the stack.


The easiest ( and almost correct ) way to look at it is, the heap is memory as you generally think of it. The stack is a reserved piece of continuous memory reserved by the JIT engine for optimizing types that meet a certain criteria.




For a much more detailed explanation ( on a subject with a lot of misinformation ) from the man who is probably the second most knowledgeable person on C# read here and here.


It will basically tell you everything you needed to know.


I think a source of much of the confusion is the stack in C++, where the programmer had much more implicit control. In C# to be honest, I don't really know why they even made the distinguishment. They should have probably ignored the concept completely and made it something only the compiler developers were really aware of. Worst case scenario, for those few edge cases where the developer needed to optimize for stack usage, it could have been exposed as an attribute. Actually, there is already the stackalloc method, so even this wouldn't be need.