Extrapolating it to a larger sense, this SO thread explains it a little bit.
The GC since the top answer has changed quite a bit; I'd read about the changes to the .net clr/framework since v5/6
as a human, it is obvious from that snippet alone that the variable x is never read. therefore, unless `classes.ElementAt(i).Name` has some side effect, the entire loop could be replaced with a no-op without changing the program semantics.
so my question isn't about GC behavior at all. I expect the entire loop to be optimized away (no code emitted). why doesn't c# make this optimization? is it something subtle about how properties work, or does the compiler not attempt these optimizations in general?
.ElementAt() OTOH has a chance to throw in most implementations AFAIR so yeah, a bit of a moot point in this case.
Edited to add:
Actually, there -could- still be side effects in the case of .Name on a class, specifically, it's possible that .ElementAt() could return a null. I'm not sure what cases (if any) that the JIT could get around that.
OTOH, in the case of a struct, as long as .ElementAt() -doesn't- throw, .Name will always return regardless of if it is a property or field, and as part of a struct the compiler should do a good job of inlining as long as the access has no side effects (and you don't have too many fields on the struct!)
It's kind of down to C# being compiled into bytecode and then JIT compiled at run-time. During the initial compilation phase, the compiler doesn't necessarily have enough information to know whether `ElementAt()` or `Name` has side effects. (I assume here that Name is a property getter and not a field, in keeping with .NET conventions.) And then at run time the JIT compiler isn't as aggressive as an AOT compiler would typically be about optimization, so it may be less likely to do any dead store elimination.
On top of this recent advancements in .net have lead to native AOT.
Something to look into.
Microsoft has been making major moves in how c# gets compiled (AOT/JIT/Native). This is a concurrent effort to cross-platform support.
In doing going so they've minimized performance differences with other languages. The only thing they've yet to completely tackle is memory handling, so in reality, while it might not seem like it at first, your question is asking about that subject.
The GC is responsible for allocation and destruction.
And thread management.
> The only thing they've yet to completely tackle is memory handling,
And thread management.
Async/Await did a whole lot to help with concurrency, IValueTaskSource and IThreadPoolWorkItem helped bring the allocation cost for that back down...
But I still don't have a good way to, say, hint to the scheduler that 'these async work loops are important enough that I want them to always run in this dedicated group of threads'.
Also, having a way to get high precision Sleep() without hacks that have impact on the rest of the system would be nice too.
Putting side effects in an `ElementAt` implementation would be an extremely bad idea, but C# won't actually stop you.
So these optimizations would have to occur in the JIT and might come at the cost of worse startup time or memory usage.
Fwiw modern .net is getting pretty good at devirt but I don't expect it would optimize all this out.
to me, all of the benchmark code looks like an obvious opportunity for dead store elimination. especially this loop in the second round:
it doesn't look like any side effects are possible there and x is never referenced outside of the loop. can anyone ELI5 why the compiler generates any code for that snippet?