RUST_BACKTRACE performance

[worik]

Friends

Is there any runtime penalty for enabling RUST_BACKTRACE?

I expect there is a space penalty to store the required data. Is there any speed penalty?

On a related note, since there must be some speed penalty to maintain the data, is there any significant speed penalty? Where does it happen?

I think it wold be mildly useful in my production code, but....

[jumpnbrownweasel]

This earlier thread in 2021 only mentions the overhead when a panic occurs, not any overhead, or lack of overhead, for simply enabling it. So this is not a complete answer.

Why isn't RUST_BACKTRACE=1 always set?

Capturing a backtrace can be expensive (depending on the platform), so running with RUST_BACKTRACE will hurt performance of programs that panic frequently. However, I think that the majority of Rust programs do not recover from panics frequently (or at all), so I agree that having backtraces enabled would be a more sensible default. The few programs that need to worry about the performance impact could easily opt out of backtrace logging. This Reddit comment notes that, at the time backtraces…

[quinedot]

@worik

Is there any runtime penalty for enabling RUST_BACKTRACE?

I expect there is a space penalty to store the required data. Is there any speed penalty?

The environment variable doesn't change what's stored, that's a compile time matter. debug and strip are the relevant compile-time options. How much difference does it make, I'm not sure of. Note also that backtraces are usually possible (or possible to attempt anyway) even with no extra information stored, as it's an operating system operation to inspect the call stack.

The variable effects panics whether and explicit backtraces attempt to capture backtraces. If you don't have either of those (or if your panics all result in termination or other scenarios where you don't care about performance), it's not going to make a difference.

There's an unstable api to change the behavior dynamically, too.

[worik]

Thank you

My conclusion is that there is no glaring price to pay in using RUST_BACKTRACE

I was concerned that I was missing something obvious. My concerns are allayed.

@quinedot

The environment variable doesn't change what's stored, that's a compile time matter

That is a very good, and obvious, point. Thank you for that.

SO I am going to leave it in the environment, it does no serious harm.

From our conversation I draw the conclusion that it is only relevant during panics, and during panics I care little about efficient execution.

Awesome help, thank you

[Vorpal]

One thing not mentioned above, is that if you use crates like anyhow or eyre, the same environment variable will by default also be used to determine if stack traces should be captured for normal Errors as well. That might well have a larger impact, as they tend to be more common than panics.

If I remember correctly, you can then use a separate environment variable to disable capturing backtraces on errors for those libraries, but please refer to the documentation in those cases.