系统与基础设施danluu.com
终端与 Shell 的性能
Terminal and shell performance
2017 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Dan Luu 用高速摄影机实测了各种终端模拟器和 shell 的按键到屏幕显示延迟，发现许多流行终端（如 iTerm2）延迟高得惊人，而看似老旧的 xterm、Terminal.app 反而最快。文章还延伸讨论了输入延迟对交互体验的影响，以及现代软件为何普遍比几十年前的更慢。
为什么经久不衰：它用可复现的测量方法揭示了一个被忽视的问题——延迟而非吞吐量才是交互体验的关键，多年来反复引发终端开发者改进性能，至今仍是理解响应式 UI 的经典参考。
HN 评论精选
iTerm2 作者解释延迟问题的技术难点，以及 Terminal.app 快的原因
iTerm2 作者：我会花时间研究 iTerm2 的延迟问题，肯定有些容易改进的地方。但也有用户抱怨延迟太低——在 shell 提示符下按回车时，下一帧应该显示新的提示符，而不是新提示符被读取前光标先跳到下一行。所以这很难做对，尤其 macOS 的文字绘制很慢。用 Core Text 在 2015 款 MacBook Pro 上为 4K 显示器绘制一帧轻松超过 150ms。Terminal.app 为什么那么快？据我所知他们抛弃了 NSScrollView，把滚动条粘到自定义 NSView 上并自己实现了惯性滚动逻辑，第三方开发者很难效仿。
gnachman查看英文原文
iTerm2 author here. I'll spend some time looking into iTerm2's latency. I'm sure there are some low-hanging fruit here. But there have also been a handful of complaints that latency was too low—when you hit return at the shell prompt, the next frame drawn should include the next shell prompt, not the cursor on the next line before the new shell prompt has been read. So it's tricky to get right, especially considering how slow macOS's text drawing is. If I could draw a whole frame in a reasonable amount of time, this problem would be much easier! But I can't. Using Core Text, it can easily take over 150ms to draw a single frame for a 4k display on a 2015 macbook pro. The deprecated core graphics API is significantly faster, but it does a not-so-great job at anything but ASCII text, doesn't support ligatures, etc. Using layers helps on some machines and hurts on others. You also lose the ability to blur the contents behind the window, which is very popular. It also introduces a lot of bugs—layers on macOS are not as fully baked as they are on iOS. So this doesn't seem like a productive avenue. How is Terminal.app as fast as it is? I don't know for sure. I do know that they ditched NSScrollView. They glued some NSScrollers onto a custom NSView subclass and (presumably) copy-pasted a bunch of scrolling inertia logic into their own code. AFAICT that's the main difference between Terminal and iTerm2, but it's just not feasible for a third-party developer to do.
Terminal.app 的优秀源于 Apple 的用心打磨；超低延迟体验确实神奇
这其实说明了 Apple 在 Terminal.app 上倾注了多少心血。它有很多贴心的小功能（显示当前 pty 上的进程、option 点击快速移动光标、对 vim 等的完整鼠标支持等），同时依然快速流畅。另外我玩过文中引用的 <1ms 延迟触摸屏系统，那种感觉真的很神奇——它真的像在拖动一个实体物件，为此他们用了定制 DLP 投影仪和定制触摸控制器，没有操作系统、没有窗口系统。
nneonneo查看英文原文
I think one thing that this really points out is just how much care Apple has poured into Terminal.app. It's very good, and every time I have to use another terminal application (ugh conhost.exe) I am reminded of this. It's got a bunch of really thoughtful little features (showing what processes are attached to the current pty, option-clicking to move the cursor rapidly, full mouse support for apps like vim, good linewrap detection, and recently support for rich-text copy/paste which is useful for showing coloured terminal output, etc. etc.), and it remains really fast and snappy despite these features. On a related note, I am big into latency analysis and driving down latency in interactive systems. I'm quite familiar with the touchscreen work cited at the top, and having played with the system I can attest that <1ms latency feels actually magical. At that level, it really doesn't feel like any touchscreen you've ever used - it genuinely feels like a physical object you're dragging around (the first demo of the system only let you drag a little rectangle around a projected screen). It's amazing what they had to do to get the latency down - a custom DLP projector with hacked firmware that could only display a little square at a specified position at thousands of FPS, a custom touchscreen controller, and a direct line between the two. No OS, no windowing system, nada. After seeing that demo, I can't help but believe that latency is the one thing that will make or break virtual reality - the one thing that separates "virtual" from "reality". I want to build a demo someday that does the latency trick in VR - a custom rig that displays ultra-simple geometry that has sub-millisecond latency to human head movement. I will bet that even simple geometry will feel more realistic than the most complex scene at 90 FPS.
Alacritty 作者回应：延迟改进有明确路径，但存在帧同步的权衡
Alacritty 可以做得更好，我已在 issue tracker 上提交了延迟来源的分析。归根结底这是个权衡：终端可以做到 1 帧输入延迟（约 1/60 秒）但放弃垂直同步出现撕裂，或者保持垂直同步但最坏情况 2 帧延迟（约 32ms）。
jwilm查看英文原文
We can do better in Alacritty. For those interested, I've filed a bug on our issue tracker about where this latency is coming from and what can be done: https://github.com/jwilm/alacritty/issues/673 At the end of the day, there is a trade off to be made. Terminals (or any program, really) can have 1-frame input latency (typically 1/60sec) and give up v-sync and tearing results, or they can have a worst-case 2-frame input latency with v-sync, and then you're looking at 2/60sec or ~32ms.
以音乐演奏类比说明延迟的感知阈值，呼吁业界重视降低延迟
作为键盘演奏者，超过 10ms 的延迟就会明显降低体验，100ms 的按键到发声延迟会让乐器无法演奏。耳朵能察觉极小的延迟：偏移 1-2ms 就有回声感，50ms 就会跑拍。我不明白人们为何容忍大量不必要的延迟——如今一切都卡。我希望 2020 年代的关键词不是提高性能，而是把该死的延迟降到不可察觉的水平。
romwell查看英文原文
As a keyboard player, I can tell you that anything over 10ms latency noticeably degrades the experience. 100ms of keypress-to-sound latency makes the instrument unplayable. Your ears will detect very small latencies; offset something just by 1-2ms, and you get an echo feel; 50ms will be off-beat. (Organ players have to deal with that kind of latency on their instrument[1], but it's a hard skill to learn, and limits the music that can be performed on the instrument. Say, following a drummer is out of the question.) Why people tolerate huge amounts of unnecessary latency is beyond me. And everything is laggy these days. Except MIDI/audio setups, that is. And even in that scene, Android got a low-latency API only last year. I say, the decade of 2020 will be not about increasing performance, but decreasing the goddamn latency down to unnoticeable levels. Or I really hope so. [1]https://music.stackexchange.com/questions/30454/how-does-a-pipe-organist-deal-with-latency-or-delay
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选