Book Club 1/2026: C#, Without Allocation

I'm not very good at coding for performance. I can do some rudimentary profiling, and if you give me a couple metrics to optimize for I can do a pretty good job getting those numbers down. When I sit down to write a piece of software though, performance is maybe my second or third concern, after ensuring the software works properly, it's well-formed (for readability and extensibility), it's well-documented, I can deploy it easily, and the like. Intentionally, I write software both in a language/runtime and in the sorts of domains for which this approach works.

I don't think that every engineer on a team needs to be extremely performance-focused. We have colleagues who are fantastic at performance, and I hold their contributions to a high esteem. At the same time though, it's no good allowing anyone to think it's alright for an engineer to neglect developing a decent knowledge of engineering for performance, and it should especially be discouraged for anyone to not consider performance altogether. The worst offense would be to develop a habit of slopping performance concerns on our performance colleague; often code written without an eye towards performance is code that can't be made more performant.

I know plenty of folks will disagree with my enumerating "performance" among the sorts of skills that software engineers can have - for the above reason no less - but the fact is that there are many different sorts of considerations that need to be held in the head of a software engineer, and it's natural that we will each be good at some considerations but not all of them. Again, this is not to give anyone a reason to neglect performance. Instead, this presents an opportunity to ask: how frequently do you review your own code through a performance lens?

My answer is "not as frequently as I'd like," which I think is a good opportunity to practice more performant development. One aspect of writing performant code, particularly in a garbage-collected language like C#, is to consider how the runtime allocates data. Reducing allocations in languages like C# or Java isn't just about making sure less memory is used - more memory use also increases garbage collector time, which can result in its own set of difficult-to-debug issues if left unchecked. Using the wrong kind of object (class/struct) depending on your use case can cause copying where there doesn't need to be any.

Fortunately, we don't need to go looking through IL to be able to learn some fundamentals that can significantly help us here! I've collected some resources on writing allocation-free C#. Notice: there's a lot of repeated information between the sources isn't there?

Before listing these links though, I want to point everyone to one of my favorite C# engineers, though I have never spoken with them. Yoshifumi Kawai (@neuecc) and their company Cysharp have published a wealth of open-source projects that provide a master class in practical, performant C#. From a zero-allocation LINQ implementation to maybe the fastest binary (de)serializer for .NET, I am a huge fan.

Reading

• Reduce memory allocations using new C# features - MSDN
• Making .NET code less allocatey - Allocations and the Garbage Collector - Maarten Balliauw
• Optimising .NET code: Hunting for allocations - Jonathan George
• Zero-Allocation Patterns in Modern .NET Web APIs - Sukhpinder Singh
• Zero allocation code in C# and Unity - Sebastiano Mandalà
• Writing zero-allocation code with C# - Sergey Nazarov

Writing

• Writing Allocation Free Code in C# - Matt Ellis
• Writing C# without allocating ANY memory - Nick Chapsas
• Pushing C# to the limit - Joe Albahari
• Exploring NET's Memory Management — A Trip Down Memory Lane - Maarten Balliauw

And a preview of more performance things...

• High-performance code design patterns in C# - Konrad Kokosa