Software Is 10x Slower Because of Architecture, Not Code
Software runs 10 to 100 times slower than it needs to, and the root cause is not coding technique but serial dependencies at the architecture layer; correct optimization means fixing the hardware's theoretical peak and then measuring the gap — which requires that whoever makes the architecture decisions understands assembly.
The video won't play here. Listen to the audio instead:
The argument · tap a timestamp to hear it
Performance is ignored for incentive reasons, not technical ones
Casey argues that developers broadly do not care about performance, and the mechanism has three layers. In enterprise software the user is not the buyer, and the decision-maker looks only at cost, compliance and legal liability — whether performance is good or bad does not affect whether the deal closes. Monopoly effects make platforms like social networks hard to challenge on performance, because no matter how bad the experience gets, users cannot leave. The third reason is that the people who have spent the last decade arguing for performance have had an effect, and performance is being taken seriously again. Stacked together, the three explain why ‘making software fast’ so often has no standing inside a company, and they show that the performance problem is fundamentally an incentive problem.
— Casey MuratoriProfile first, then optimize is not how experts work
Casey stresses that the genuine optimization experts in the industry do not profile first and then go fix the hot spots. The correct order is: first ask what operations this system actually has to perform, then look up what the underlying hardware can do at its theoretical peak, then measure the gap between that theoretical maximum and the current implementation, and finally work to close the gap. This has two benefits: you do not get pulled off course by local hot spots, and you discover new hardware features, which in turn raises your own optimization ability. He states plainly that ‘measure the hot spots first, then optimize’ is not the expert approach — it treats optimization as after-the-fact repair.
— Casey MuratoriThe serial dependency chain sets the performance ceiling during architecture
The real problem with ‘premature optimization is the root of all evil’ is this: if a serial dependency chain forms during the architecture phase, no amount of later hot-spot optimization can rescue it. Casey's example is a code pattern of ‘request, process, request again’ — a performance expert can do nothing with it, because serial dependencies cannot be parallelized. Software performance is usually determined by the longest serial dependency chain, and that chain is locked in at architecture time. So once the architectural choice is wrong, every subsequent performance optimization is building on the wrong foundation.
— Casey MuratoriAI companies are paying off the previous generation's language debt
Uber once moved to Go and Java because of single-threading problems with Python and Node.js. Today OpenAI and Anthropic face the same story: data scientists know Python, so the first version was all Python, but the product has to support multithreading and more connections, and they are now starting to evaluate migrating to Rust or Go. Casey's implication is that AI companies are living through an infrastructure ‘language debt’ period, and that this scene already played out at the previous generation of internet companies. History is repeating.
— Casey MuratoriGTA6 is slow because it has to replace the company's money printer
Casey explains GTA6's long development cycle in terms of business structure: GTA5 Online was at the time the highest-earning entertainment product there was, taking in billions of dollars a year. GTA6 is not making a new game, it is replacing the company's most profitable product, so Rockstar and Take Two cannot fail, and they also have to plan the online portion so the new product does not cannibalize the old product's revenue. GTA5's success was an accident for them; GTA6 is the first time they are genuinely updating the flagship product, the equivalent of re-releasing Google Search. That is extremely conservative development logic.
— Casey MuratoriThe real cost of virtual functions is the compiler not daring to optimize
Many people assume the overhead is in the virtual function call itself. Casey corrects this: the real cost is that the compiler loses its ability to optimize. When the compiler cannot determine the runtime type, it cannot inline, cannot merge redundant code, cannot vectorize — and the performance loss is far larger than one indirect call. The degradation he demonstrated in the Clean Code video was relatively mild by comparison; real production environments may be worse. What makes polymorphic code slow is not that single dispatch, but that all of the surrounding code loses its eligibility to be automated.
— Casey MuratoriIn their own words · checked verbatim
That is not how anyone has ever, you know, I've worked with many extremely good optimization people, and that is not how it is done. The correct way to do optimization is very much like what you just said. You first go, what are the operations that this system has to perform? What is the underlying hardware capable of doing at its theoretical peak? And then you measure the delta between that theoretical maximum and what you have achieved.
Casey Muratori22:29
The performance of your software is generally determined by the longest serial dependency chain because it's something that cannot be paralyzed.
Casey Muratori33:53
The way to think about it is your code base will not end up that way by accident. In most cases anymore. You have to engineer up front for a hotspot code base that people can then optimize.
Casey Muratori35:56
Grand Theft Auto 5 at the time was, if I'm not mistaken, by far the most revenue generating entertainment product in existence. The online part of that game was generating like billions of dollars.
Casey Muratori1:13:25
in my experience, usually the code that is architected properly is also the code that runs quickly.
Casey Muratori1:25:13
I don't think people should necessarily take a book recommendation from me. I want to recommend that people read a paper.
Casey Muratori1:50:13
I don't know if they're good at that, but I'm guessing that's something they could do.
Casey Muratori1:51:15
Figures
| How much slower software runs than it needs to | 10x-100x | 0:00 |
| Linear's operation budget | 300ms | 19:22 |
| Network ping time | sub 10ms | 20:25 |
| Assembly instructions for A+B in Python | Far more than C's single add instruction | 44:26 |
| Games released on Steam per year | Tens of thousands to a hundred thousand | 1:07:59 |
| Performance gap in the Clean Code video | 1.5x to 15x | 1:16:32 |
| GTA5 Online revenue | Billions of dollars | 1:13:25 |
| Turning point in AI code quality | January 2024 | 1:38:46 |
| Time needed to fully evaluate AI | At least 6 months to a year | 1:39:47 |
Glossary
- theoretical peak
- The maximum throughput hardware can reach under ideal conditions; the benchmark against which optimization targets are set.
- serial dependency chain
- A sequence of operations that cannot be parallelized and must execute in order, setting the floor on software latency.
- hotspot
- The part of a program consuming the most CPU time, often the natural entry point for optimization.
- branch prediction
- The CPU mechanism that predicts which way a branch will go in order to keep the pipeline full; a wrong prediction is expensive.
How to listen
Programmers writing backend or business code, architects making technology choices, and startup teams currently rewriting their stack with AI — and especially anyone whose product is slow but who cannot say where the slowness lives.
If you are short on time, skip the Clean Code video retrospective from 1:16 to 1:25 and just take the conclusion; the game industry section looks like a digression but is actually the most predictive material in the episode.