跳到主内容
@wquguru
精选70The Pragmatic Engineer(RSS)产品与增长

性能为何重要却被忽视:Casey Muratori 谈优化方法

Why performant code matters (but gets widely ignored), with Casey Muratori

原文
发到 X

Stream the latest episode

播放最新一集

Listen 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.

现在即可在YouTube、Apple和Spotify上收听和观看。本页顶部有节目文字记录,底部有节目时间戳。

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.

• Antithesis——通过激进故障注入运行整个系统,为您的系统测试加速。Jane Street、Fly.io和etcd社区等团队依赖Antithesis,这绝非偶然。了解更多。

• 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.

• Sentry——由开发者打造、为开发者服务的应用监控软件。Sentry的Seer AI代理是他们新推出的精巧工具之一,我曾用它快速修复后端错误。查看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.

• turbopuffer——基于对象存储构建的向量和全文检索引擎。它快速、廉价且极具可扩展性。我在旧金山见过他们的团队,非常欣赏他们“硬核又奇思妙想”的工程文化,以及他们务实的工程哲学。去看看他们吧。

In this episode

本期内容

There 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.

当今世上,恐怕很少有人比本期播客嘉宾Casey Muratori更关心软件性能了。他是一位程序员和电子游戏开发者,是Molly Rocket的创始人,也是Handmade Hero的创作者——这是一个长期系列节目,讲述如何从零开始构建游戏。他还在自己的Substack专栏《Computer, Enhance》中积极宣扬性能的重要性。

We got to know each other about three years ago, first via messages, including this one from Casey:

大约三年前我们相识,最初是通过消息交流,包括Casey发来的这条:

“Why does the industry zeitgeist place so little emphasis on software performance when there seems to be overwhelming evidence that performance is critical to their bottom line?

“为什么行业潮流对软件性能如此不重视,而大量证据却表明性能对其利润至关重要?

Like you, I run a Substack for professional programmers, but I focus exclusively on software performance. Although we are quite large by Substack standards, so a certain subset of programmers must believe performance is important, I nonetheless hear lots of dismissive excuses when I post on social media. This happens so frequently, I devoted an entire article to cataloging the extensive pro-performance evidence we already have from the world’s leading software companies: Performance Excuses Debunked.

和你一样,我为专业程序员运营一个Substack专栏,但我只专注于软件性能。虽然按Substack的标准我们规模相当大,所以一定有一部分程序员认为性能很重要,但我在社交媒体上发帖时,仍听到许多不屑一顾的借口。这种情况频繁发生,以至于我专门写了一整篇文章,整理我们已从世界领先软件公司获得的广泛支持性能的证据:《性能借口大揭穿》。

Strangely, nobody has a rebuttal to why performance is important. When I point people to this, they actually tend to agree. But the prevailing attitude nonetheless stays the same.”

奇怪的是,没有人对性能为何重要提出反驳。当我向人们指出这一点时,他们实际上往往表示同意。但主流态度却依然如故。”

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.

我很高兴终于请到了Casey来参加播客,因为这件事早就该做了!在这一集中,我们讨论了为什么软件性能很重要,为什么它常被忽视,以及开发者如何能更好地编写高性能代码。我们探讨了为什么在设计阶段就应该考虑性能,学习阅读汇编语言和理解CPU工作原理的价值,Casey对‘整洁代码’的批评,以及他为什么认为测试不应驱动软件设计。

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.

我们谈到了电子游戏开发的变化,以及有影响力的游戏引擎。Casey还告诉我们为什么他更喜欢手写代码,而不是用AI,以及其他内容。

Takeaways from the conversation with Casey

与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.

1. 如果没有微软内部一个‘未经授权’的项目,DirectX可能就不会存在。DirectX是一个非常流行的微软库,它标准化了GPU上的渲染,主要用于游戏。Casey讲述了Chris Hecker如何在微软构建了一个用于快速屏幕渲染的库,名为WinG,这个项目从未被授权;它完全是一个‘臭鼬工厂’项目。DirectX的根源可以追溯到WinG,而DirectX的三位创始人都曾是WinG的测试者。

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?

2. 性能开始对企业重要了吗?企业软件买家主要关心成本、合规性和功能——但不关心性能。尽管如此,仍有一些产品因其性能而获得了巨大的流行度和市场份额,例如File Pilot(下一代文件浏览器)和Blick视频编辑器。潮流是否正在转变?

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.

3. 基于分析器的性能优化是错误的优化方式。标准的优化方法是分析应用程序,调整热点,然后检查统计数据是否有所改善。但这只能找到局部最小值;Casey说,他共事过的每一位优秀的‘优化者’工程师,都是先确定硬件理论上能做什么,然后不达目的不罢休,直到缩小差距达到那个性能水平。

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:

4. 如果你关心性能,学会阅读汇编语言(不需要会写)。你需要学习大约20到30条指令,才能阅读基本的汇编代码。例如,下面是一个计算5 + 3 - 1(结果为7)然后打印出来的程序:

An assembly program calculates 5+3-1 (the first 3 lines after _start), then prints the result to stdout

一个汇编程序计算5+3-1(_start之后的前三行),然后将结果打印到标准输出

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!

5. 对于“过早优化是万恶之源”这一传统智慧,应持保留态度。许多开发者以此为借口推迟性能优化,但Casey指出,不及时优化可能意味着后期只能修复性能热点,而无法解决导致性能不佳的架构问题。应从一开始就设计出高性能的系统架构,否则若不重写,将难以解决问题!

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:

6. 理解CPU工作原理只需掌握三件事。Casey认为,了解这些就能从任何CPU发布中大致判断其性能表现。这三个理解支柱是:

  • How data moves in and out: load/store units and L1–L3 caches
  • How instructions flow through the pipes: branch prediction, i-cache
  • Execution unit scheduling: raw throughput per operation type
  • 数据进出方式:加载/存储单元及L1–L3缓存
  • 指令在流水线中的流动:分支预测、指令缓存
  • 执行单元调度:每种操作类型的原始吞吐量

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.

7. 游戏工作室为何如此保密?在可授权视频游戏引擎出现之前,游戏引擎是工作室的“核心”知识产权(IP),每个工作室都从零开始构建渲染、寻路等工具。暴雪就是这样将《魔兽争霸1》的引擎延续到《魔兽争霸2》的。任何竞争对手制作竞品游戏都必须从零开始,这也是游戏工作室严密保护自家游戏引擎工作原理的原因之一。

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.

8. 游戏行业已经经历了它的“AI时刻”——而且并不美好。当游戏引擎变得可授权后,几乎任何开发者都能借助Unity和Unreal等引擎,在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.

起初,这一变化让新开发者得以创作有趣的游戏。但很快,市场每年被成千上万的游戏发布淹没,破坏了自然发现机制。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.

9. 老游戏不再显得过时,这成了一个问题。几十年来,图形一直是展示电子游戏随时间进步的重要标尺;1995年的新作在视觉上必然优于1990年的作品。但2026年的新游戏与九年前的游戏相比,看起来可能并无太大差异,而新作还要面对老游戏的持续竞争。

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.

10. Casey对测试驱动开发的不满在于“测试”这一部分。Casey认为测试应基于成本效益决策,而非默认实施。对于某些项目,提前进行测试——甚至在某些情况下进行任何测试——都是糟糕的选择。

11. One trait of almost every great engineer: refusing to accept programming wisdom untested in the real world. As Casey puts it:

11. 几乎所有伟大工程师的一个特质:拒绝接受未在现实世界中验证的编程智慧。正如凯西所说:

“I find there’s a lot of received programming wisdom that’s just nonsense. Clearly, no one’s ever tested it. In order for something to be received wisdom, you should have to at least demonstrate concrete upsides, but often this cannot be done. I would say focusing on what actually works in practice is a huge plus.”

“我发现有很多流传的编程智慧纯属胡说八道。显然,没有人真正测试过它们。要让某件事成为公认智慧,你至少应该展示出具体的优势,但这往往做不到。我认为,专注于实践中真正有效的东西是一个巨大的加分项。”

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:

12. 凯西即将推出的游戏中没有AI。他承认许多开发者会不同意,但坚持认为偏离主流品味并无不妥,就像有些人选择手工家具而非平板包装家具一样。他省略AI的理由很简单:

“I want to program things in a game because I want to program them. If I only wanted output, I’d just get the Unreal Engine.”

“我想在游戏中编程,因为我想编程。如果我只想要输出,我直接就用虚幻引擎了。”

The Pragmatic Engineer deepdives relevant for this episode

《务实工程师》深度探讨了与本集相关的内容

更进一步:量化金融体系

看懂新闻只是起点——沿量化金融路径,把它变成能交付的工程能力

进入量化体系 →

相似阅读

另一事件,读法相近