RUST_BACKTRACE = 1有多少开销？

Question

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

它是否在正常执行期间（例如在函数调用期间）引入任何（重要的？）开销，或者只是在发生恐慌时才会产生开销？

Answer 1

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

  

我认为除了恐慌时它没有效果

Answer 2

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

请注意，此标志也会影响编译器本身（rustc）。编译器有时会发出恐慌以导致“正常”退出，抑制打印回溯但仍在计算它。在编译错误后退出时会发生这种情况。在过去，人们已经报告这导致编译器的某些版本需要很长时间才能退出并设置RUST_BACKTRACE=1。

某些包装箱也可能自己处理RUST_BACKTRACE：例如，error_chain包装箱会在生成错误并设置RUST_BACKTRACE=1时生成回溯。这可能会减慢使用此箱子的项目速度。使用error_chain的值得注意的项目是cargo。

Answer 3

这对我感兴趣，因为Rust Playground会like to have RUST_BACKTRACE enabled all the time，但目前速度差异不足以忽略不计。从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中，只需启用它caused 10-20 seconds of delay on certain platforms！在此之前，我从未注意到任何缓慢。

编辑方面，启用RUST_BACKTRACE时编译的Rust代码的性能似乎不是Rust团队的主要关注点。除此之外，还有许多其他有趣的东西需要评估！由于这些原因，我不愿意一直这样做。当然，如果编译器本身默认打开设置，那么我会期望它更值得关注！