3 ms·

The new collection syntax is succinct and aesthetically pleasing but a step back in terms of functionality and information conveyance. The new syntax should hav

The new collection syntax is succinct and aesthetically pleasing but a step back in terms of functionality and information conveyance. The new syntax should have been introduced but reserved only for allocation-free (heap, that is) expressions where the result is a Span and kept the explicit new() requirement for any dynamic heap allocations. As it is currently, the new collection syntax may result in dynamic heap allocations or it may not - it’s fully opaque.

CharlieDigital 3y ago
To be fair, I think most devs aren't thinking about heap allocations; probably just want a collection. If one needs to initialize it with performance considerations in mind, it is still possible to do so.
- 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 ago
    Speaking 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.

3 ms·

The new collection syntax is succinct and aesthetically pleasing but a step back in terms of functionality and information conveyance. The new syntax should hav

by ComputerGuru 3y ago

CharlieDigital 3y ago
To be fair, I think most devs aren't thinking about heap allocations; probably just want a collection. If one needs to initialize it with performance considerations in mind, it is still possible to do so.
- 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 ago
    Speaking 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.