Jack Grigg

Possibly, but something else appears to also be going on here. I tried manually reverting to `bitvec 0.22.3` via patching, and while that does gain a bit of performance back,...

https://github.com/zcash/zcash/issues/6049#issuecomment-1175462075 is another report of slow rescanning performance.

@freebeego you are seeing this issue. I'm investigating.

I annotated `CWallet::ScanForWalletTransactions` with metrics, and from the data derived a "microseconds per transaction" metric for Sapling and Orchard trial-decryption ("scan" in the figures) and witness appending. The first two...

I changed the plots from `us/transaction` to `us/block` (which is closer to a per-bytes metric, as tx sizes can vary), and some of the weirdness in the Orchard append behaviour...

Hmm, actually I think the base cost might be the assertion checking that the node and wallet computed the same Orchard commitment tree root: https://github.com/zcash/zcash/blob/e03b964abffac285a066ba496f16cf2cd73cf61c/src/wallet/wallet.cpp#L2695-L2696 This is evaluating the root...

Nope, definitely the assertion on `orchardWallet.GetLatestAnchor()`: 

In PR gardening today, we identified the likely cause of the baseline: the empty roots aren't being cached in `incrementalmerkletree`: - https://github.com/zcash/incrementalmerkletree/blob/070a7588aeebec9c2b72586b119bcafab8ecf633/src/bridgetree.rs#L567-L575 ```rust fn root_at_altitude(&self, alt: Altitude) -> H {...

We're going to fix the issue with `GetLatestAnchor()` in a point release of `incrementalmerkletree` (as that is an order of magnitude effect that will be noticeable again if the blocks...

Just to confirm the expected behaviour, I added a second account (prior graphs were scanning with a single account) and rescanned:    We indeed observe that the absolute...