Bump anyhow to 1.0.80 and drop backtrace crate #263
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On the Windows VM, the
indexer::start()
command we use in LSP initialization takes over 40 seconds to complete when run in thevctrs/
project. On a Mac, this typically takes a few milliseconds.This is a bigger difference than just computer horsepower.
The way the indexer code is written is a little strange,
index_function()
andindex_comment()
end up propagating an anyhow error upwards in the extremely common cases where no match is found, even though this error is immediately discarded inindex_node()
. These anyhow errors always capture backtraces from what I can tell, so they actually have non zero cost to create, in particular on Windows apparently! Theindex_function/comment()
functions are called hundreds of time, so this adds up.With anyhow 1.0.71, the backtrace crate was used for backtrace capture, but in >=1.0.77 with Rust >=1.65, it started using the standard library's new backtrace support.
dtolnay/anyhow#293
rust-lang/rust#64154
They also encourage you to stop enabling the backtrace feature, as it is always on in Rust >=1.65 now:
Switching to anyhow 1.0.80 (current release) somehow ends up fixing the performance issue. My guess is that std backtraces are either lazier or just way faster to capture on windows.
I consider this a "quick fix" and intend to rewrite the indexer code in a follow up PR to have an API that works more off
Option
thanResult
, avoiding this entirely (hopefully making it faster on all platforms).Side note, I originally thought this was related to this anyhow performance regression:
dtolnay/anyhow#347
But that seems to actually be unrelated and is a different scenario (there upgrading to 1.0.80 actually hurt performance, i think they previously were not capturing backtraces at all and all of a sudden they started to do so)