本文共 2994 字，大约阅读时间需要 9 分钟。

Rust 编译缓慢的根由在于语言的设计

作者介绍

Brian Anderson 是 Rust 编程语言及其姊妹项目 Servo Web 浏览器的共同创始人之一。他目前在 PingCAP 担任高级数据库工程师。

感谢 Rust 中文社区翻译小组对本文翻译及审校上的贡献：

• 翻译：张汉东、黄珏珅
• 审校：吴聪

Rust 编译缓慢的根由在于语言的设计

人们常说，语言的设计是一个不断权衡的过程。最主要的权衡就在于运行时性能和编译时性能之间的平衡。而 Rust 团队偏向于追求更好的运行时性能，这一选择直接导致了 Rust 的编译时表现不尽如人意。

Rust 与 TiKV 的编译时冒险：第 1 集

我们基于 Rust 开发了分布式存储系统 TiKV。然而，它的编译速度慢到足以让公司里的许多人不愿使用 Rust。我最近花了一些时间，与 TiKV 团队及其社区中的其他几人一起调研了编译时间缓慢的问题。

这篇文章将探讨以下几个方面：

PingCAP 的阴影：TiKV 编译次数 “余额不足”

在 PingCAP，我和我的同事用 Rust 写存储节点。选择 Rust 是因为希望 TiKV 在最大程度上能够快速且可靠地构建。我发现，这个决定很棒，团队的人对此也非常满意。

然而，大家对编译时间的抱怨却让我有些无奈。比如，在开发模式下，完全重新构建需要花费 15 分钟，而在发布模式则需要 30 分钟。对于大型系统项目的开发者来说，这样的速度或许并不太糟糕。然而，与许多开发者从现代开发环境中期望得到的速度相比， TiKV 却显得过于缓慢。

TiKV 是一个相当巨大的代码库，拥有 200 万行 Rust 代码。而 Rust 本身包含超过 300 万行 Rust 代码，TiDB 中的其他节点是用 Go 编写的。PingCAP 的一些 Go 开发人员对不得不等待 Rust 组件的构建表示不满，因为他们习惯于快速的构建-测试迭代。

Rust 编译缓慢的根由在于语言的设计

继续深入，我们需要理解为什么 Rust 编译时间如此糟糕。这并非语言设计的本意。实际上，语言设计者们总是必须在运行时性能和编译时性能之间权衡，而 Rust 团队倾向于更关注运行时性能。这种根本性的权衡使得 Rust 的编译时间陷入了一个死循环。

尽管如此，Rust 的设计理念并不完全是单纯为了编译速度。它的核心设计目标包括以下几点：

尽管编译速度不是 Rust 设计的核心目标，但它却成为了某种程度的附带问题。事实上，Rust 的设计历史也让它一步步深陷了糟糕的编译时性能沼泽。

Rust 的自举： why? how?

我并不记得自己什么时候才开始意识到，Rust 的糟糕编译时间其实是一个战略性问题。在面对未来底层编程语言竞争时，这可能是一个致命的错误。在最初的几年里，我几乎完全是对 Rust 编译器进行 Hacking。对编译时间的问题，我当时并不太关心，也不认为其他大多数同事会太在意。我印象中，大部分时间 Rust 的编译速度总是很糟糕，但我觉得自己能处理好。

我通常会在计算机上至少保留三份存储库副本，方便在其他编译器都在构建和测试时，专注于其中一份进行修改。这一行为可能也是其他 Rust 开发者的日常。然而，这种零碎化的工作流程显然不是高效的开发方式。而每次构建工作都需要切换上下文，增加了工作负担。

Rust 的自举： else?

从历史上看，Rust 的自举（Self-Hosting）时间一直很糟糕。自举指的是使用 Rust 来构建它自己的编译器。Rust 的自举编译时间在过去几年里发生了怎样的变化？通过这些建议和数据，我们可以看到：

次要因素

除了上述根本性原因，还有一些语言设计上的因素可能对编译性能产生影响：

改善 Rust 编译时间的最新进展

现状不是否没有改善的希望。许多工作正在努力改善 Rust 的编译时间，但仍有许多途径可以探索。我最近一两年了解的进展包括：

下集预告

多年来，Rust 将自己深深地逼进了一个死角。它糟糕的编译时表现几乎成了一种“必然性”，而不是一个“可解决的问题”。TiKV 的构建速度还能让我的管理者满意吗？答案可能取决于以下几个方面：

在下一集中，我们将深入探讨 Rust 语言设计的细节，这些细节会不会继续导致它编译缓慢？新一代的 Rust 开发者是否能改变这一现状？一言启стати文，朋友们！

鸣谢

许多人参与了本系列博客。特别感谢 Niko Matsakis、Graydon Hoare 和 Ted Mielczarek 的真知卓见，以及 Calvin Weng 的校对和编辑。

wantonda 热门文章推荐

[关键词：Rustück, TiKV, 编译优化]

[展示相关文章链接]