views:

576

answers:

3

Has anyone ever actually used stackalloc while programming in C#? I am aware of what is does, but the only time it shows up in my code is by accident, because Intellisense suggests it when I start typing static, for example.

Although it is not related to the usage scenarios of stackalloc, I actually do a considerable amount of legacy interop in my apps, so every now and then I could resort to using unsafe code. But nevertheless I usually find ways to avoid unsafe completely.

And since stack size for a single thread in .Net is ~1Mb (correct me if I'm wrong), I am even more reserved from using stackalloc.

Are there some practical cases where one could say: "this is exactly the right amount of data and processing for me to go unsafe and use stackalloc"?

+4  A: 

stackalloc is only relevant for unsafe code. For managed code you can't decide where to allocate data. Value types are allocated on the stack per default (unless they are part of a reference type, in which case they are allocated on the heap). Reference types are allocated on the heap.

The default stack size for a plain vanilla .NET application is 1 MB, but you can change this in the PE header. If you're starting threads explicitly, you may also set a different size via the constructor overload. For ASP.NET applications the default stack size is only 256K, which is something to keep in mind if you're switching between the two environments.

Brian Rasmussen
Is it possible to change the default stack size from Visual Studio?
configurator
@configurator: Not as far as I am aware.
Brian Rasmussen
+12  A: 

The sole reason to use stackalloc is performance (either for computations or interop). By using stackalloc instead of a heap allocated array, you create less GC pressure (the GC needs to run less), you don't need to pin the arrays down, it's faster to allocate than a heap array, an it is automatically freed on method exit (heap allocated arrays are only deallocated when GC runs). Also by using stackalloc instead of a native allocator (like malloc or the .Net equivalent) you also gain speed and automatic deallocation on scope exit.

Performance wise, if you use stackalloc you greatly increase the change of cache hits on the CPU due to the locality of data.

Pop Catalin
Locality of data, good point! That's what managed memory will rarely achieve when you want to allocate several structures or arrays. Thanks!
Groo
Heap allocations are usually faster for managed objects than for unmanaged because there's no free list to traverse; the CLR just increments the heap pointer. As for locality, sequential allocations are more likely to end up colocated for long running managed processes because of heap compaction.
Arnshea
+4  A: 

I have used stackalloc to allocate buffers for [near] realtime DSP work. It was a very specific case where performance needed to be as consistent as possible. Note there is a difference between consistency and overall throughput - in this case I wasn't concerned with heap allocations being too slow, just with the non determinism of garbage collection at that point in the program. I wouldn't use it in 99% of cases.

Jim Arnold
Hey Drew :-) How's it going? This is a pretty ghetto IM client.
Jim Arnold