Possible performance regression on Windows about anyhow

[nwalfield]

I just 1.0.80, and I'm seeing the same performance issue. Reverting back to 1.0.76 fixes the issue.

[nwalfield]

I traced the regression down to d6acd22.

I added the following to our Cargo.toml:

[patch.crates-io]
anyhow = { git = 'https://github.com/dtolnay/anyhow.git', rev = 'b91db55c4eb21611832bba2eef4300d2816e1d04' }

And then changed the revision until I found the earliest commit (according to git log) that exhibits the performance issue in our CI. That was d6acd22200de94b65804e08ca41a4bdff3404512. The preceding commit 5121cd2, appears to be fine.

[decathorpe]

This looks like the backtrace functionality that was stabilized in the Rust std is performing differently / worse than the one in the external backtrace crate, especially on the x86_64-pc-windows-msvc target?

---

EDIT: Looks like with Rust >= 1.65, backtrace support is now enabled unconditionally, so rather than things being slower with std than with the external backtrace crate, it looks like the cause might actually be that backtrace support is now enabled unconditionally whereas it wasn't enabled before (sequoia-openpgp does not use the "backtrace" feature of anyhow).

[LPGhatguy]

Hello, I just stubbed my toe on this too and wasted a few hours combing through our dependency upgrades.

This change ruins the performance of our game on Windows. Capturing a single backtrace on Windows takes enough time to cause noticeable hitching. That's a huge amount of time spent on backtraces that my users aren't even seeing!

Edit: It seems like setting RUST_LIB_BACKTRACE=0 will force backtrace captures off on errors and fix all of the performance lost.

[workingjubilee]

The ~current nightly version of the standard library should have performance improvements for obtaining backtraces, specifically on Windows. I would be interested in knowing how bad the regression is, comparatively, in applications compiled with the recent nightly stdlib (versus those compiled with the latest stable, which will be slightly behind that).

Note that I do expect it will still be very harsh, but it will at least use a less... clumsy, ancient, deprecated API for obtaining the trace.