4 ms·

I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite ever

I strongly disagree. The vast majority of extant .NET APIs encourage or require allocating memory dynamically, thereby requiring GC. Sure, if you rewrite everything that isn't already defined in terms of `Memory` or `Span`, you can do it, but that's a _tall_ order. Even supposing you still mange to write a whole program that doesn't allocate dynamic memory, or that quickly stabilizes around a finite `ArrayPool`. You're still pulling in all the runtime GC machinery. Further, the minute someone _else_ contributes code, you run the risk of allocating again. As much as I love C#, _this isn't its niche_.

Const-me 6y ago
> vast majority of extant .NET APIs encourage or require allocating memory dynamically A lot of APIs in modern .NET already supports spans. They can be backed by anything, not just GC-managed memory. For that project, some of these spans are backed by the memory mapped by V4L2 or ALSA API calls. Others are backed by unmanaged buffers allocated on startup with Marshal.AllocHGlobal. For small temporary stuff I use stackalloc, e.g. both mp4 and mkv use tons of variable-length encoded integers. > the minute someone _else_ contributes code, you run the risk of allocating again. Good point. On the other hand, someone else contributing code can introduce any bugs at all, not just GC-related performance issues. > As much as I love C#, _this isn't its niche_. A while ago some people were saying the same about C, and were instead coding assembly :-)