RUST_BACKTRACE = 1有多少开销？

Question

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

它是否在正常执行期间(例如在函数调用期间)引入任何(重要的？)开销,或者在发生恐慌时是否只有开销？

Answer 1

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

我相信它除了在恐慌期间没有任何影响

Answer 2

这对我很感兴趣，因为 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 团队目前最关心的问题。除此之外，还有许多其他有趣的事情需要评估！由于这些原因，我不愿意一直戴着它。当然，如果编译器本身默认开启了该设置，那么我希望它更值得关注！

Answer 3

函数中是标准库中唯一读取RUST_BACKTRACE环境变量的位置sys_common::backtrace::log_enabled()。该函数只能panicking::default_hook从中调用，而在发生恐慌后才调用该函数。因此，除非线程出现紧急情况，否则对其进行设置应该不会对性能产生任何影响。

请注意，此标志还会影响编译器本身（rustc）。编译器有时会发出紧急情况以导致“正常”退出，从而抑制打印回溯，但仍在对其进行计算。当它在编译错误后退出时，可能会发生这种情况。过去，有人报告说，这导致某些版本的编译器需要很长时间才能退出RUST_BACKTRACE=1set。

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