potential performance regression on windows

[AxelNennker]

Hyperledger Indy moved back from backtrace 0.3.33 to 0.3.11 because it seems the Windows performance worsened. Please see
hyperledger-indy/indy-sdk#1763

Would be nice if you could look into this. Thanks

[alexcrichton]

Thanks for the report! Is there any more information to go along with this? This is unfortunately not really actionable just knowing "windows might be slow"

[AxelNennker]

I don't have a Windows system to test this.
Would the benches here reveal such a regression?

Currently Indy is before a release so the core team is really busy.
I'll write a PR to libindy that uses the 0.3.33 version and see how the windows CI reacts.
Although the Jenkins jobs are currently often terminated because of the pre-release load.

Sorry, I have not more data now. // CC @Artemkaaas @KitHat

[alexcrichton]

Ok, some small performance testing reveals two culprits for the change in performance, although there could be more:

• First is Ignore return of SymInitializeW on Windows #231, which will get fixed if that's merged. The problem is that SymInitializeW, an expensive operation, is called on each call to Backtrace::new.
• Second is that support for generating a backtrace inlined function frames on MSVC has been added. This manifests in the usage of StackWalkEx instead of StackWalk64 where supported, and this also changes the symbolication routines.

The former is relatively easily fixed, the second isn't really fixable AFAIK. A configuration option could be added to the crate for whether you want accurate or fast backtraces, but that's about the only solution there.

[AxelNennker]

The Indy project is building a C-callable library libindy from Rust source code. So, I guess, we don't care about inlined function frames too much. Thanks for looking into this and publishing 0.3.34 so quickly. We'll give that a try soon.

[alexcrichton]

Ok thanks for testing it out, I think if it's an acceptable level of performance we can probably leave it as-is, otherwise I can look into providing a build-time option to forcing usage of older functions on Windows.

[Artemkaaas]

I did testing of backtrace=0.3.34 on our CI (windows machine).
The usual time of running tests (with usage backtrace=0.3.11) is about ~ 23-28 minutes.
With backtrace=0.3.34 it took about 50 minutes. I tried twice.
Looks like the problem still presents for windows.

[alexcrichton]

Oh wow that's quite the regression! If that jumps so much it seems like the majority of your CI time even before may have been capturing backtraces. Mentioned above I think the StackWalk64 strategy is just fundamentally faster than StackWalkEx since it parses less information. It sounds like in y'all's use case though backtraces are being generated a bit too much in the test suite?

[alexcrichton]

I'm going to close this since it's been quite some time and I don't think this is going to fundamentally change. If there's something we can do to still get an accurate backtrace but amortize the cost though please let me know!

[caldempsey]

@alexcrichton not sure if this helps but I benched creating 10 million UUIDs and writing them to a file in Rust using https://github.com/mmacheerpuppy/rust-10m-uuid, the performance is worse on Windows by a magnitude of about 30, may have something to do with the filesystem support! Totally not sure if related but wanted to bring it to your attention in case this gives you a lead

[alexcrichton]

@mmacheerpuppy hm that seems unrelated to this crate? Are backtraces generated there?