Practical use of `stackalloc` keyword

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 chance of cache hits on the CPU due to the locality of data.

Stackalloc initialization of spans. In previous versions of C#, the result of stackalloc could only be stored into a pointer local variable. As of C# 7.2, stackalloc can now be used as part of an expression and can target a span, and that can be done without using the unsafe keyword. Thus, instead of writing

Span<byte> bytes;
unsafe
{
  byte* tmp = stackalloc byte[length];
  bytes = new Span<byte>(tmp, length);
}

You can write simply:

Span<byte> bytes = stackalloc byte[length];

This is also extremely useful in situations where you need some scratch space to perform an operation, but want to avoid allo­cating heap memory for relatively small sizes

Span<byte> bytes = length <= 128 ? stackalloc byte[length] : new byte[length];
... // Code that operates on the Span<byte>

Source: C# - All About Span: Exploring a New .NET Mainstay

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.

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.