This isn't related to heap allocations. It's about removing the cost of a stack variable being moved into another stack variable.

I became interested in stack performance specifically because I had to avoid heap allocations.

I mean, it's tangentially related, sure. It's also related to ML because computers run ML algorithms and computers run programs with stacks.

While I want to understand your point and welcome enlightenment, so far this conversation has just been kinda weirdly hostile.

Using structs, stack allocations (safe since C# 7.x) and native heap go a long way.

Many of the post C# 7 features have been used to improve .NET performance in techpower benchmarks, and rewrite runtime code from C++ into C#.

You can also use generic functions that take struct arguments instead of delegates to get something like STL. I wish there was some syntactic sugar in the language for that, too - basically, struct lambdas.

There is a bit of that with static lambdas, function pointers (unsafe), but still isn't quite what you want.

Well, until relatively recently, they wouldn't be able to desugar what I really want into underlying bits. But now that we have verifiable ref structs with ref fields in them in C# 11, it's a straightforward transformation. Might be worth a proposal, actually...

You can access C#'s GC metrics through `System.GC.GetTotalAllocatedBytes` and similar APIs. Maybe you can make a benchmark and tracker for it yourself!