4 ms·
C# devs are a bit less allocation-blind than in some other ecosystems due to the from-the-beginning distinction between value and object types, the availability
by ComputerGuru 3y ago
C# devs are a bit less allocation-blind than in some other ecosystems due to the from-the-beginning distinction between value and object types, the availability of manual stack allocation, and a general awareness of the pathological behavior of some dev-friendly but performance-deadly LINQ expressions. The recent introduction and heavy focus on Span and Memory<T>, source generators, etc have also done much to raise awareness of dynamic allocations and runtime overhead. It’s in light of this that I view choosing to paper over allocations a misguided effort.
- neonsunset 3y agoSpeaking of LINQ, depending on your use case, I suggest re-evaluating the intuition regarding its performance in specific scenarios. Both .NET 7 and especially .NET 8 have seen a lot of work to improve the underlying performance of LINQ and thanks to DynamicPGO certain patterns that used to be very unfriendly to performance now have (sometimes significantly) lower cost. The speed-up depends on the use case but expect to see anything from 10% up to >200-400% improvement.