Big-O of Zero—${\rm O}\left(0\right)$

Basically everyone who learns to program at some point learns about Big O notation. Most people are taught that the fastest algorithms are on the order of ${\rm O}\left(1\right)$. Not even close. The fastest are ${\rm O}\left(0\right)$.

What's ${\rm O}\left(0\right)$? It's the speed of not doing work. Most of the software performance problems you're likely experiencing aren't slow algorithms, or even shared resource contention, they're just waste. The vast majority of performance is being wasted doing a bunch of work that nobody needed done. Some routine examples I find are things like repeatedly serializing and deserializing or copying and reallocating objects that didn't need to be copied. Wrapping something in a for-loop that involves overhead for each iteration that could be eliminated by doing it in one go. Doing all sorts of make-work under the guise of "best practices," being able to handle "arbitrary" inputs, or satiate some sense of aesthetic taste.

${\rm O}\left(0\right)$ is what happens if you stop solving imaginary problems. It's what happens if you talk to your users/customers and find out what they actually need done. It's leaving boundaries until after you understand what the code actually needs to do instead of arbitrarily splitting up the problem over function calls, modules, or network stacks right at the start.

I'm serious, most of the optimization work I do is making code run in ${\rm O}\left(0\right)$. Simple example, there's a server that passes data to another. That second system's only job is to put that data in a database and send a message to yet another server. Don't ask me why, but it's a real example. Anyway, it was too slow. Accepting the data and putting it in the database was taking over 10 seconds. Why is it taking this long? A mountain of reasons, but the simplest was that it was JSON deserializing the data and using JSON schema to do input validation on a payload it was getting from a trusted system. It then re-serialized it and put it in a database, storing the data in a JSON column which caused the database to again deserialize it and normalize it for storage.

Why was it doing all this work? "Best practices." It's just what services do. How did I fix it? Accept the data as a binary payload and put it into a binary blob column. I'd have removed the whole thing but I can only exert so much influence. Now it takes a couple seconds, basically all of it on network overhead.

I find it funny just how much I constantly want to cut away at the system until it does only what it really needs to. It's why I remember formatting and reinstalling my first MS-DOS machine because it was too cluttered. Why my Linux of choice has gone from Ubuntu to Arch to Void. Why I often replace dependencies I added in the prototype with my own code once I understand what really needs to be done.

When your computer is busy doing things you really don't need it to be doing, it's wasting your time. It's a fun flame war to watch when people talk about how fast or slow a language or framework is. Fast or slow software's first order approximation is based on the knowledge you have in doing things that don't frivolously waste time.

I could type all day giving you example after example, but I'll just leave you with the pocket Mike Acton:

1. Can we not do this at all?
2. Can we do this only once?
3. Can we do this fewer times?
4. Can we approximate the results so no one notices?
5. Can we use a small lookup table?
6. Can we use a small FIFO?
7. Can we constrain the problem further?