How We Found 7 TiB of Memory Just Sitting Around

The app should write records to a database? Fine. Here's where you configure the connection. The app in production is slow because the database server is weak? Not my problem, talk to your DBA.

The app should expose an HTTP endpoint for liveness probes? Fine. It's served from the path you specified. Your reused it for an external outage check, and that's reporting the service is down because the route timed out due to your ops team screwing up the reverse proxy? Literally not my problem, I could not care less.

You know why? I am not saying that what you said does not make sense. Of course it does make sense, financially so. But! You the manager one day come to me and my team and say "How could we allow to have 7TB of unused memory sitting around and we paid for it?!" and we'll then have multiple follow-up meetings where we'll be scolded and "trained" how to avoid things like this. We'll get sent articles and told to improve.

And believe me when I tell you, _all_ the techies in these meetings want to roll their eyes through it all. Because many of them likely asked "Can I take a closer look at our infra, it seems expensive and we can potentially optimise it?" and were said no by managers like yourself.

As an engineer you just can't win. So I don't blame myself or any other techie who sometimes goes cowboy mode to find such problems without asking.

Finally, "my contribution for the month" is technological work and nothing else. If I wanted to be a cofounder or have a seat in the board so I have fiduciary duty, I would have said so. It's your job as a manager to put this barrier between stakeholders and front soldiers so the latter can do their thing without disruption, so the organisation can succeed.

Are you doing your job well?

Microservices try to fix that. But then you need bin packing so microservices beget kubernetes.

I always liked Shaw’s “The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”

My first job out of college, I got handed the slowest machine they had. The app was already half done and was dogshit slow even with small data sets. I was embarrassed to think my name would be associated with it. The UI painted so slowly I could watch the individual lines paint on my screen.

My friend and I in college had made homework into a game of seeing who could make their homework assignment run faster or using less memory. Such as calculating the Fibonacci of 100, or 1000. So I just started applying those skills and learning new ones.

For weeks I evaluated improvements to the code by saying “one Mississippi, two Mississippi”. Then how many syllables I got through. Then the stopwatch function on my watch. No profilers, no benchmarking tools, just code review.

And that’s how my first specialization became optimization.

The sandwich view hides invocation count, which is one of the biggest things you need to look at for that remaining 3x.

Also you need to think about budgets. Which is something game designers do and the rest of us ignore. Do I want 10% of overall processing time to be spent accessing reloadable config? Reporting stats? If the answer is no then we need to look at that, even if data retrieval is currently 40% of overall response time and we are trying to get from 2 seconds to 200 ms.

That means config and stats have a budget of 20ms each and you will never hit 200ms if someone doesn’t look at them. So you can pretend like they don’t exist until you get all the other tent poles chopped and then surprise pikachu face when you’ve already painted them into a corner with your other changes.

When we have a lot of shit that all needs to get done, you want to get to transparency, look at the pile and figure out how to do it all effectively. Combine errands and spread the stressful bits out over time. None of the tools and none of the literature supports this exercise, and in fact most of the literature is actively hostile to this exercise. Which is why you should read a certain level of reproval or even contempt in my writing about optimization. It’s very much intended.

Most advice on writing fast code has not materially changed for a time period where the number of calculations we do has increased by 5 orders of magnitude. In every other domain, we re-evaluate our solutions at each order of magnitude. We have marched past ignorant and into insane at this point. We are broken and we have been broken for twenty years.