Why performant code matters (but gets widely ignored), with Casey Muratori
Why performant code matters (but gets widely ignored), with Casey MuratoriCasey Muratori explains why software performance matters, how developers can write faster code, and why he challenges conventional engineering practices.
Stream the latest episodeListen and watch now on YouTube, Apple, and Spotify. See the episode transcript at the top of this page, and timestamps for the episode at the bottom. Brought to You by
• Antithesis – turbocharge testing of your systems by running your whole system under aggressive fault injection. There’s good reason teams like Jane Street, Fly.io, and the etcd community rely on Antithesis. Learn more. • Sentry – application monitoring software built by developers, for developers. Sentry’s Seer AI agent is one of their new, neat tools, which I’ve used as a way to quickly fix errors on my backend. Check out Sentry. • turbopuffer – A vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. I met their team in San Francisco, and am a fan of their “hardcore and whimsical” engineering culture, and how pragmatic their engineering philosophy is. Check them out. In this episodeThere can be few people around who care about software performance more than today’s pod guest, Casey Muratori. He’s a programmer and videogame developer, founder of Molly Rocket, and creator of Handmade Hero – a long-running series about building a game from scratch. He also evangelizes about performance on his Substack, Computer, Enhance. We got to know each other about three years ago, first via messages, including this one from Casey:
I’m delighted we finally have Casey on the podcast because it’s overdue! In this episode, we discuss why software performance matters, why it’s overlooked, and how developers can get better at writing performant code. We explore why performance should be considered during design, the value of learning to read assembly & understanding how CPUs work, Casey’s critique of ‘clean code’, and why he believes testing shouldn’t drive software design. We touch on how videogame development has changed, and influential game engines. Casey also tells us why he prefers to write code by hand, not with AI, and more. Takeaways from the conversation with Casey
1. DirectX might not exist without an “unauthorized” internal Microsoft project. DirectX is a very popular Microsoft library that standardized rendering on top of GPUs, used mostly for games. Casey tells how Chris Hecker built a library for fast on-screen rendering at Microsoft called WinG, which was never authorized; it was a total “Skunk Works” project. DirectX’s roots go back to WinG, which its three founders were testers on. 2. Is performance starting to matter to businesses? Enterprise software buyers care mainly about cost, compliance, and capabilities – but not performance. Even so, there are some products gaining major popularity and market share due to their performance, such as File Pilot (next-gen file explorer) and the Blick video editor. Is the tide turning? 3. Profiler-driven performance optimization is the wrong way to optimize. The standard way of optimizing is to profile the application, tweak hotspots, then check if the stats have improved. But this only finds a local minimum; Casey says every engineer he’s worked with who was a great “optimizer” began by establishing what the hardware could theoretically do, and then did not stop until they’d closed the gap to that performance level. 4. If you care about performance, learn to read assembly (no need to write it). There are about 20-30 instructions you need to learn to be able to read basic assembly. For example, here’s a program that calculates the value of 5 + 3 - 1 (which is 7), then prints it out:
5. Take a grain of salt with conventional wisdom that premature optimization is the “root of all evil”. Many devs use it as an excuse to delay performance optimization, but Casey says that not optimizing in time could mean that only performance hotspots can be fixed later, and not the architectural issues that create poor performance. Architect your system to be performant, or you’ll have trouble solving problems without a rewrite! 6. Only three things are needed to understand how CPUs work. Casey believes that knowing them means you’ll be able to tell from any CPU announcement roughly how well it performs. Those three pillars of understanding:
7. Why are game studios so secretive? Before licensable videogame engines existed, the game engine was a studio’s “core” intellectual property (IP), and every studio built rendering, pathfinding, and other tools from scratch. This is how Blizzard rolled Warcraft 1’s engine into Warcraft 2. Any competitor making a rival game had to start from scratch, which was a reason for game studios to closely guard the secrets of how their own game engines worked. 8. The games industry already had its “AI moment” – and it wasn’t pretty. When game engines became licensable, pretty much any developer could build and publish a game with the likes of Unity and Unreal, on a platform like Steam. Initially, this change empowered new devs to build interesting games. But soon enough, the market was flooded with tens of thousands of releases per year, which destroyed organic discovery. Without a marketing strategy, the chances of a game gaining traction today are basically zero, says Casey. 9. Old games don’t look dated anymore, and that’s a problem. For decades, graphics were a vital barometer for showing how videogames improved over time; a new release in 1995 was guaranteed to be visually superior to one from 1990. But a new game in 2026 likely doesn’t look much different from one that’s nine years old, and new releases face ongoing competition from older games. 10. Casey’s problem with test-driven development is the “test” bit. Casey believes tests should be a cost/benefit decision, and not put in place by default. For some projects, doing tests upfront – or doing any tests at all, in some cases – is simply a bad choice. 11. One trait of almost every great engineer: refusing to accept programming wisdom untested in the real world. As Casey puts it:
12. No AI in Casey’s upcoming game. He acknowledges that many developers will disagree, but insists there’s nothing wrong with being outside of mainstream tastes, just like some people chose handmade furniture over the flatpack kind. His reasoning for omitting AI is straightforward:
The Pragmatic Engineer deepdives relevant for this episode• Pushing software engineering limits with “napkin math” with Simon Eskildsen • How Games Typically Get Built: prototyping, game engines, and a different type of QA • Game Development Basics: deepdive on how game studios differ from standard software teams • Inside Linear’s Engineering Culture: building a performant product with a tiny team • Building a best-selling game with a tiny team – with Jonas Tyroller. A two-person team built a game that sold 1M+ copies More on premature optimization: read or watch Casey’s extended take on “premature optimization is the root of all evil”: 
Timestamps00:00 Intro 05:17 Games at Microsoft 12:52 Building games 16:00 Why performance matters 27:12 Why you should learn to read assembly 30:36 Designing for optimization 42:51 How to get better at writing performant software 49:04 Understanding how the CPU works 55:53 Building games then and now 1:05:56 How game engines changed building games 1:10:48 Why new games compete with old games 1:13:25 GTA 6: why is it taking so long? 1:16:59 Casey’s critique of clean code 1:21:48 Casey’s take on TDD 1:24:30 What is good code? 1:27:32 What makes a good software engineer? 1:33:56 Why Casey doesn’t code with AI 1:39:01 AI’s impact on the game industry 1:44:43 AI and burnout 1:50:21 Why you should read papers ReferencesWhere to find Casey Muratori: • Website:
• Substack: https://substack.com/@cmuratori Mentions during the episode: • Digital Equipment Corporation: https://en.wikipedia.org/wiki/Digital_Equipment_Corporation • VAX 9000: https://en.wikipedia.org/wiki/VAX_9000 • Intel: https://www.intel.com • Chris Hecker’s website: https://www.chrishecker.com/Homepage • Doom: https://en.wikipedia.org/wiki/Doom_(franchise) • Wolfenstein 3D: https://en.wikipedia.org/wiki/Wolfenstein_3D • WinG: https://en.wikipedia.org/wiki/WinG • Ron Gilbert: https://en.wikipedia.org/wiki/Ron_Gilbert • Humongous Entertainment: https://en.wikipedia.org/wiki/Humongous_Entertainment • The Secret of Monkey Island: https://en.wikipedia.org/wiki/The_Secret_of_Monkey_Island • DirectX: https://en.wikipedia.org/wiki/DirectX • Todd Laney on Tumblr: https://toddla.tumblr.com • Craig Eisler on LinkedIn: linkedin.com/in/craigeisler • Eric Engstrom: https://en.wikipedia.org/wiki/Eric_Engstrom • Dungeon Siege: https://en.wikipedia.org/wiki/Dungeon_Siege • RAD Game Tools: https://www.radgametools.com • Alex St. John: https://en.wikipedia.org/wiki/Alex_St._John • Molly Rocket: https://mollyrocket.com • File Pilot: https://filepilot.tech • Bun: https://bun.com • npm: https://www.npmjs.com • Napkin math: https://github.com/sirupsen/napkin-math • Fortnite: https://www.fortnite.com • Minecraft: https://www.minecraft.net • Roblox: https://www.roblox.com • GTA online: https://www.rockstargames.com/gta-online • Unreal Engine: https://www.unrealengine.com • Ken Silverman’s website: https://advsys.net/ken • id software: https://www.idsoftware.com • Bullfrog Productions: https://en.wikipedia.org/wiki/Bullfrog_Productions • Thief: The Dark Project: https://en.wikipedia.org/wiki/Thief:_The_Dark_Project • Death Rally: https://en.wikipedia.org/wiki/Death_Rally • Grand Theft Auto V: https://www.rockstargames.com/gta-v • “Clean” Code, Horrible Performance:
• TDD, AI agents and coding with Kent Beck: https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent • Python, Go, Rust, TypeScript and AI with Armin Ronacher: https://newsletter.pragmaticengineer.com/p/python-go-rust-typescript-and-ai — Production and marketing by Pen Name. You’re on the free list for The Pragmatic Engineer. For the full experience, become a paying subscriber. Many readers expense this newsletter within their company’s training/learning/development budget. If you have such a budget, here’s an email you could send to your manager. This post is public, so feel free to share and forward it. If you enjoyed this post, you might enjoy my book, The Software Engineer's Guidebook: navigating senior, tech lead, staff and principal positions at tech companies and startups.
|
%26stroke%3Dnone%26strokeWidth%3D3.6){kind=small}
Comments
Post a Comment