我对快速终端的误解

Lobsters Hottest 工具

摘要

作者纠正了之前关于快速终端的说法,指出基准测试方法有缺陷,像 antidote 这样的现代插件管理器不会增加开销,并推荐了更快的语法高亮器。真正的偏好是简洁,而不仅仅是速度。

<p><a href="https://lobste.rs/s/pf0tx3/what_i_got_wrong_about_fast_terminals">评论</a></p>
查看原文
查看缓存全文

缓存时间: 2026/06/09 01:24

# 关于快速终端,我错在哪里了 来源:https://mijndertstuij.nl/posts/what-i-got-wrong-about-fast-terminals/ 几天前,我发布了《生命太短,别用慢终端》(https://mijndertstuij.nl/posts/life-is-too-short-for-a-slow-terminal/)。这篇文章获得不少流量,还收到了那种你真正期待的反馈。 核心意思是:精简配置不再是拥有快速终端的唯一方法。我以前根本不知道这些方法,只能凭借自己已有的知识来优化。幸运的是,Zsh 社区有很多聪明的人。 所以,下面我来逐条指出那篇文章的不足之处,因为做出更正比辩解更有价值。 ## 我衡量了错误的东西 这一点让人有点难受,因为测量占了那篇文章的一半。我以这样的开头: ``` $ for i in {1..5}; do /usr/bin/time zsh -i -c exit; done ``` `time zsh -i -c exit` 启动一个交互式 shell 并立即关闭它。这是大家惯用的基准测试,但 `zsh-bench`(https://github.com/romkatv/zsh-bench#how-not-to-benchmark)中专门有一节解释为什么它是错误的。它测量的是总初始化时间加上关闭时间,但总初始化时间并不是你要等待的。你真正等待的是:提示符出现、第一个命令运行、以及之后每次按键的延迟。这些是不同的数字。一个配置在我的测试中可能很慢,但在实际使用中却比我的配置感觉更快。 `zsh-bench`(https://github.com/romkatv/zsh-bench)衡量的是你实际感受到的东西:首次提示符出现时间、第一个命令运行时间、命令延迟和输入延迟。如果让我重写测量章节,我会引导大家使用它,而不是一个 `time` 循环。 更大的失误在于 **即时提示符**(https://github.com/romkatv/zsh-bench#instant-prompt)。它在 shell 启动时就渲染一个缓存的提示符,在 `.zshrc` 完成之前就已经显示,这样你可以在剩余的初始化在后台进行的同时开始打字。一旦 shell 做到这一点,我引以为傲的退出时间数字几乎无关紧要,因为无论初始化成本如何,感知上的启动时间接近为零。我的 30ms shell 和 300ms 但带有即时提示符的 shell,在唯一重要的时刻体验完全相同:当你坐下开始输入时。 ## “插件管理器会增加开销”这个说法太宽泛了 我写道,插件管理器“会额外增加自己的开销”并且“在启动时进行依赖解析”。这对某些管理器来说是真的,但如此概括整个类别就显得不够严谨。 `antidote`(https://github.com/mattmc3/antidote)维护一个简单的插件列表,并将其编译成一个单一的静态脚本,你只需要引用它。打开 shell 时不会进行任何解析,你只引用一个生成的文件——这正是我自己手写 `source` 行时所称赞的做法。所以我的说法更诚实的版本应该是:一个在每次启动时解析插件的重型框架会很慢。而现代的静态打包管理器则不会,而且它能帮你管理更新——我的安装脚本是手动处理更新的。 ## 我推荐了一个慢速的语法高亮器 在一篇关于输入延迟的文章中,我引用了 `zsh-syntax-highlighting`。回过头来看,这有点尴尬,因为它会在每次击键时重新高亮整个缓冲区,对于长命令行而言,这恰恰就是我之后章节中警告的每次按键延迟。 `Zsh-patina`(https://github.com/michel-kraemer/zsh-patina)是一个值得一试的新方案。如果你输入长命令,它的体验会比我现在用的好很多。 ## 那么,我的论点还剩下什么? 我真正喜欢的是,我可以一口气读完我的整个 `.zshrc`。没有框架替我决定事情,没有我没选择的插件,当 shell 出现异常时也不需要二分查找。当有东西变慢时,我能找到它,因为里面内容很少。这确实是一种偏好,但这是对**简洁**的偏好,而简洁恰好带来快速,只是一个副作用。你完全可以拥有一个功能齐全、感觉瞬时的快速 shell。只是达到目的的路径不同而已。 所以我会继续坚持最小化配置,但现在是以一种诚实的态度:我保持精简是因为我想理解它,而不是因为这是实现快速唯一的途径。 ## 总结 感谢那位花时间写下这些反馈、而非直接划走的读者。这是互联网上“被纠正”的美好版本。原始文章(https://mijndertstuij.nl/posts/life-is-too-short-for-a-slow-terminal/)仍然存在,顶部加了一条指向本篇的注释,配置也还放在我的 dotfiles 仓库(https://github.com/mijndert/dotfiles)中,包括语法高亮器在内。 我将会更新部分配置,使用这些更现代的工具。

相似文章

人生苦短,别用慢终端

Lobsters Hottest

本文详细介绍了通过避免框架、缓存补全以及懒加载工具来加速终端启动的实用技巧,实现了30毫秒的shell启动。

终端文本渲染的各种缺陷(2024)

Lobsters Hottest

本文探讨了终端模拟器中文本渲染的各种根本性问题,包括字符定义歧义、Unicode处理问题、有缺陷的二维网格假设以及光标不同步,凸显了支持复杂脚本和字体的困难。

快优于慢

Lobsters Hottest

一篇博客文章,主张软件开发中的速度能带来更好的学习和决策,并提供实用建议,如避免拖延和尽早分享工作。