How much overhead does RUST_BACKTRACE=1 have?

Question

Is it reasonable to just set RUST_BACKTRACE=1 always?

Does it introduce any (significant?) overhead during normal execution (such as during function calls) or is there only overhead when a panic happens?

Answer 1

The only place in the standard library that reads the RUST_BACKTRACE environment variable is in the function sys_common::backtrace::log_enabled(). That function is only called from panicking::default_hook, which gets called after a panic occurs. Therefore, setting it should have no effect on performance unless a thread panics.

Note that this flag also affects the compiler itself (rustc). The compiler sometimes issues panics to cause a "normal" exit, suppressing printing the backtrace but still calculating it. This can happen when it exits after a compilation error. In the past, people have reported that this caused some versions of the compiler to take a long time to exit with RUST_BACKTRACE=1 set.

Some crates may also handle RUST_BACKTRACE themselves: For example, the error_chain crate generates a backtrace when an error is generated and RUST_BACKTRACE=1 is set. This can slow down projects using this crate. A notable project which uses error_chain is cargo.

Answer 2

I asked about this in #rust-internals, and sfackler said

I believe it has no effect except during a panic

Answer 3

This is of interest to me as the Rust Playground would like to have RUST_BACKTRACE enabled all the time, but currently the speed difference is not negligible enough. As of Rust 1.19.0, there is some overhead even for a simple "hello world" program which does not panic or cause a compiler error:

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

• compile and execute - RUST_BACKTRACE=1 cargo run
• execute - CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUNNER='env RUST_BACKTRACE=1' cargo run
• disabled - cargo run

The overhead has not been consistent over time; In 1.14.0, simply having it enabled caused 10-20 seconds of delay on certain platforms! Before then, I never noticed any slowness.

---

Editorially, it does not appear that the performance of compiled Rust code when RUST_BACKTRACE is enabled is currently a prime concern of the Rust team. There are many other interesting things to evaluate, besides! For these reasons, I would be loathe to have it on all the time. Of course, if the compiler itself turned on the setting by default, then I would expect it to be much more attention-worthy!