kuanat

eBPF ftw!

赞一个！

妙哉！

这个审核很迷，年初帮朋友做个项目申请没过就改用第三方的了。然后过了大概半年突然发邮件说违规把 ses 停了，又过了几天说封错了，结果 ses 权限就莫名其妙开了。

稍微偏个题。

编程这件事的本质是什么？我个人有个粗糙的定义，就是用语言对某种事物、行为或过程做出无歧异的抽象描述。用自然语言给人指路、教人下棋或者介绍产品都是编程，只是这种程序的执行者不是自动化的机器。

从计算理论上说，图灵完备的编程语言之间不存在表达能力的差别。语言特性和编程范式百花齐放，表面上是工具特化的结果，深层次是反映编程者对于现实的认知逻辑和思维方式。

FP 是数学上优美的，非常适合解决真空中球形鸡的问题，现实大多数问题仍旧需要传统经验公式和手段来应对。OOP 是有效解构对世界认知的哲学，但实现 OOP 的方式却不一定。组合（ composition ）替代继承（ inheritance ）就是认知层面的进步。

从过去二十年编程语言的发展来看，语言特性 FP/OOP 的进步演化一直在发生，但几乎不存在相互替代的基础。作为工具的编程语言，以当下的视角来看，能够成为主流的一定是具有工程化能力基础的，只有解决问题的范畴和效率提升才会带来工具的替代。

@lysShub #71

没有说怎么测的，我也没细看，就假定它用的一致的测试方法好了。延迟测试包含了语法分析，但是因为它只是在新的一行里反复按了 10 次 z ，所以这个语法分析的时间可以忽略不计了。

我这里简单就 Zed 官网宣传的一些特性简单做个总结，同时与 VS Code 对应的部分做个对比。


1. 输入延迟

Zed 在性能方面有个对比，强调的是 Insertion latency ，58ms 相对 VS Code 97ms 算是非常优秀了。这个测试反映的是输入状态下按下按键，到字符出现在屏幕上的时间，如果你玩游戏的话，很容易理解这个就是所谓的输入延迟。

你可能觉得 40ms 影响不大，但这个特性属于有对比才有伤害、或者说像高刷屏用了就回不去那种。不仅仅是在文本编辑器领域，像终端（ vte ）领域一样对于输入延迟有追求，所以你会看到像 kitty/alacritty 这样通过 GPU 加速绘制的终端模拟器。再比如很多人会觉得 oh-my-zsh 之类的框架会拖慢 shell 的启动，考虑换成 fish 之类作为替代。

2. 渲染模式

也许你会认为 Zed 渲染快延迟小是得益于原生应用相对于 electron 的优势，是有这方面的原因，但是不够全面。同样是输入延迟部分，Sublime Text 4 大概是 75ms ，可以粗略的认为，Sublime 相对 VS Code 的优势来源于原生，但 Zed 相对于 Sublime 的优势有一部分是来自于渲染模式。

包括各种终端模拟器在内的应用，所谓的 GPU 加速更多的是使用 immediate 模式，相对于 retained 模式。前者就是把应用当作 3D 游戏，自己负责渲染每一帧。后者就是一般意义上的原生应用，使用系统控件，只有在状态发生变化时才通知系统，由系统负责渲染。

Zed 使用的是 Vulkan 后端，其 UI 界面就是基于 immediate 模式自渲染的。（技术上说，应用 GPU 加速通常更快，但不总是更快，这一点放到后面说）

3. 语法分析

如果增加一个 Deletion latency 的测试，我相信 Zed 会胜出更多的。原因是无论插入还是删除，后台都要做语法分析，从而提供高亮、补全等等功能。删除相比插入更能反应语法分析器的性能，特别是跨多行或者代码存在语法错误的时候。

Zed 的开发团队的前身就是做 Atom 的团队，而 Atom 当年之所以有底气做编辑器，是因为他们写了 Tree-sitter 这个通用的 parser 生成器。现在 Tree-sitter 是事实上最通用、也是效率最高的语法解析器的“生成器”。不是 parser 而是 parser 的生成器，这一点尤为重要。

在 Tree-sitter 之前，通用的语法解析主要是 TextMate 的，后续包括 VS Code 在内也都沿用了下来。连 VS Code 的开发都说，用 TextMate 这套的原因就是不用为每一门语言都写规则，然后他们也发现很多语言的规则都多年没人维护了。当初 TextMate 设计这个功能的时候想的是，尽可能在不用写 parser 的情况下完成 parser 的主要功能，所以实现方式是正则匹配。放到二十年后的今天来看，这个做法就跟不上时代了。

一方面现在的性能和软件实践来说，写 parser 和实时处理都相对简化了，既然都能完整实现和运行 parser 了，那就没必要用弱化版的了。另一方面，基于正则的弱 parser 实现只能处理一行，也不能支持像是“增量”处理，或者在代码被修改乱了，存在语法错误的时候还能正确输出尽可能有用的信息。

我个人认为，Tree-sitter 在这方面对于写代码的改善是非常明显的，不仅速度快结果还准确，特别是错误状态下依然有用这点十分好用。想要尝试的话可以用 neovim 或者其他基于 Tree-sitter 的编辑器感受一下。

4. 协同

现在没有什么编辑器能做到像 VS Code 的 Remote 功能一样彻底颠覆开发的工作流。即便 JetBrains 这样也算财大气粗的专业开发，照着现有的方案模仿都做得一塌糊涂。所以也不要对 Zed 有什么不切实际的期待。

Zed 目前能做到的是还是本机做 host ，然后可以编辑 remote 的文件而已，对用户隐藏了拉取和推送文件的细节。

所以 Zed 就专注做了协同功能，在本地编辑器上实现了多人实时编辑同一文档的在线编辑器体验。这个功能基于 CRDT 思路，有兴趣可以去看看。



关于“GPU 渲染为什么不会总是更快”这个说法的解释：

一般来说，GPU 渲染会更快一点，但就文本编辑器（或者终端 vte ）这个场景来说，GPU 渲染不一定比 CPU 更快。这是因为 GPU 更快是建立在全渲染的前提之上的，而文本编辑这个场景很多时间并不需要全渲染。

比如输入的时候，发生变化的一般只有当前行。浏览代码的时候，代码内容不变只是显示位置变了。这样的场景里，使用 damage tracking 类算法，就是类似 vnc/xdp 那种检测改变部分的算法，可以极大降低渲染的工作量。以游戏渲染的思路来看，无非就是 framebuffer 的手动控制更新。

所以我个人并不喜欢使用 GPU 渲染的文本编辑器或者终端模拟器。当然，如果它像浏览器那样，将字体渲染过程中的处理交由 GPU 完成，我还是很支持的。