RUST_BACKTRACE=1 有多少开销

Question

总是设置 RUST_BACKTRACE=1 是否合理？

它是否在正常执行期间(例如在函数调用期间(引入任何(重大？(开销，还是仅在发生恐慌时引入任何(重大？(开销？

Answer 1

标准库中唯一读取RUST_BACKTRACE环境变量的地方是在函数sys_common::backtrace::log_enabled() 中。该函数仅从panicking::default_hook调用，在发生恐慌后调用。因此，除非线程死机，否则设置它应该不会影响性能。

请注意，此标志也会影响编译器本身(rustc(。编译器有时会发出 panic 以导致"正常"退出，禁止打印回溯，但仍会计算它。当它在编译错误后退出时，可能会发生这种情况。过去，人们报告说，这导致某些版本的编译器需要很长时间才能退出RUST_BACKTRACE=1集。

一些板条箱也可以自行处理RUST_BACKTRACE：例如，error_chain箱在生成错误并设置RUST_BACKTRACE=1时会生成回溯。这可能会减慢使用此板条箱的项目。使用error_chain的一个值得注意的项目是cargo。

Answer 2

我在#rust-internals问过这个问题，sfackler说

我相信除了在恐慌期间之外，它没有任何效果

Answer 3

这对我来说

很感兴趣，因为 Rust Playground 希望一直启用RUST_BACKTRACE，但目前速度差异还不够微不足道。从 Rust 1.19.0 开始，即使对于一个简单的">hello world"程序，也不会惊慌或导致编译器错误，也有一些开销：

| RUST_BACKTRACE      | time (seconds) |
|---------------------|----------------|
| compile and execute |           2.48 |
| execute             |           2.02 |
| disabled            |           1.64 |

• 编译和执行 - RUST_BACKTRACE=1 cargo run
• 执行 - CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUNNER='env RUST_BACKTRACE=1' cargo run
• 禁用 - cargo run

随着时间的推移，开销并不一致;在 1.14.0 中，仅启用它在某些平台上会导致 10-20 秒的延迟！在那之前，我从来没有注意到任何缓慢。

---

从编辑上讲，启用 RUST_BACKTRACE Rust 时编译的 Rust 代码的性能似乎并不是 Rust 团队目前最关心的问题。此外，还有许多其他有趣的事情需要评估！由于这些原因，我不愿意一直戴着它。当然，如果编译器本身默认打开设置，那么我希望它更值得关注！