Micro-optimization Is My Passion
Yes it's not often needed but I love squeezing the most out of every CPU cycle. From optimized hot paths to esoteric softwaremancy, I'm all about it.
For me, working out how to get the that last bit of performance out of a CPU or memory is my favourite software challenge. As in, the bit after sensible approaches like a cache, hash tables, async/await, parallel threads, etc. I'm talking about understanding compiler emits, hardware intrinsics, and loosening safeties. I have a whole .NET cheatsheet on it:
In this post I'm off to ramble around how it's hard to justify micro-opimizations, where they're most useful, how .NET benefits from this under the hood, and what I do to chase my passion.
Optimizations as a whole
Let's talk about broad optimizations first. If you've been in software for awhile, you've probably heard:
Premature optimization is the root of all evil.
This is a quote from Donald Knuth, and I feel it gets quoted out of context as a broad hammer to snuff out work not relating to product/customer/shareholder satisfaction. Looking at the full quote:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
He's encouraging it for where it makes sense. As engineers who care about their craft and understand business needs, applying our engineering minds that 3% can make a huge impact. These are our hottest paths, most expensive paths, or our most critical paths. They deserve attention by way of caching, proper thread management, or even simply better hardware.
Micro-optimization gets a bad wrap in traditional businesses
So what happens if we need to go even further beyond in that 3%? Actually, most of the time we don't. It won't make financial sense in most businesses unless they're massively scaled globally where milliseconds or even nanoseconds make an impact to running or customer costs.
It also has a decent chance to make code either less readable (by using more esoteric features, or simply being messier) and perhaps less maintainable. For example, the fastest way I know how to write loops in C# is:
int[] items = [1, 2, 3, 4, 5];
ref var start = ref MemoryMarshal.GetArrayDataReference(items);
ref var end = ref Unsafe.Add(ref start, items.Length);
while (Unsafe.IsAddressLessThan(ref start, ref end))
{
Console.WriteLine(start);
start = ref Unsafe.Add(ref start, 1);
}An esoteric, fast loop in C#.
Which needs a lot of unsafe memory knowledge to get a grasp on - totally understandable to come across this and treat it like an armed bomb. You don't want to be the one causing a production outage by not understanding the underlying memory manipulations.
As most software written isn't by a core engineering business, you may have a lot of trouble justifying the expensive engineer cost vs the tiny improvement and perhaps reduced maintainability.
However, there is another place where these tiny gains make a big difference...
Gaming steps in
At 60 fps, you get 16.67 milliseconds of allowance per frame. Want to put more into the game without lag? Optimize. Whether of not game developers use them, there are a huge amount of tricks and I'm going to highlight one developer I follow: Yoshifumi Kawai or neuecc.
Neuecc writes zero allocation .NET libraries for game development and they've been used extensively, some you might've heard of:





I think gaming is a great place to have more of a mainstream impact when writing optimized code - at least a better chance than in most businesses that write software.
Microsoft (and the community) also steps in
Each version of .NET gets faster and faster. This is because optimizations at the base framework level impact millions of running apps in a real and material way - so it's worth putting in the effort to make one hot path a little more complex as the savings overall are worth it.
Stephen Toub writes one a post every year and the latest at the time of writing this is Performance Improvements in .NET 10. There's an incredible amount of engineering and craft across the static compiler, the JIT, and the methods/objects. So we get this out of the box, for free.
My journey with (micro)optimization
So why do I love it? "Make number go up" makes my brain tick, so games like Factorio and incremental games get at me. But what if I could apply that in real life, with real skills, with a real impact?
My first career experience of this was fresh out of university and not even a real optimization. I was using Entity Framework 6 (I believe) to do a large amount of database sync updates using a lot of Add() calls. Because of how EF6 worked, there was a lot of overhead per each of these calls. Turns out, I could have the code go from many tens of seconds to many ones (🤔) of seconds by swapping it out for the bulk version: AddRange(). This simply did the overhead once regardless of the number of rows.
Shortly after came Parallel.ForEach() that made my code go REALLY fast. But in retrospect feels like trying to do surgery while wearing oven mitts. I'm sure there were many idle CPU cycles that would've benefitted from (the emerging) async/await pattern.
Skip forward a little more but still at the same job, and I learned about the Visual Studio Profiler. A concrete way to diagnose and benchmark my code. The "make number go up" (or down) dashboard that became useful to all future jobs and do the good chemicals in my brain.
That first job of mine was an incredible space to experiment and grow. I'll forever cherish the team I was in for letting a fresh grad make messes like a toddler in front of a paint bowl.
(One more short story: at a job interview I was told about HttpClient reusage and this began my zero allocation understanding).
So what do I do now? As explained earlier, most of the time the really fun micro-optimizations aren't worth it in a business sense. Well, then DIY! As the nerd I am, I spend some of my free time on it:
- ZeroRedact - my redaction NuGet package!
- TinyWordle
- Dotnet Optimization Cheatsheet
- Optimization Tools And Notes
- mGBA-lua-socket-loadtest
Talking about TinyWordle, this is a disk size optimization experiment where we get esoteric things like
- Creating a custom app.manifest so the embedded manifest is smaller
- Moving to use P/Invoke for
Consolecalls - Removing string interpolation calls to strip away the emitted calls for them
David Fowler (Microsoft) wrote a Twitter thread on one of his step by step optimizations on his little game, which can be summed up as:
- Profile
- Use more efficient object/types/methods
- Pooling
- Allocation trimming
To conclude
I think it's really fun to work out weird ways to get code to move faster even if it makes the code a more brittle and less maintainable - because at that point either it's for my own enjoyment, or the path is so hot that it warrants it.
Just wanted to ramble on one of my favourite topics 😌✌️
And here's a tweet from Nick Craver (Stack Overflow, Microsoft) that summarises this whole post.