test: speed up send_shield_cycle from 58s to 44s - #2741
Merged
Conversation
Move zcash_local_net and zingo_test_vectors from 537f84d3d to 89cf104a2, the merge of infrastructure PR #284. Zebrad::generate_blocks now parks a long-poll getblocktemplate after each mined block, so zebrad precomputes the next shielded coinbase during harness work. Separation blocks drop from 2.5s to 0.4-1.6s, and send_shield_cycle mining drops from 28.3s to 23.2s mean. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
follow_proposal confirmed transactions with sender.sync_and_await, which raced the indexer: the wallet often synced before the indexer served the confirmation block, wasting an entire extra confirm round. Replace the bare sync with sync_client_to_tip, which barriers on indexer convergence to the mined height first. This removes the wasted confirm[1] round and saves about nine seconds per run. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
send_shield_cycle built the PostNu6_3 Orchard proving key lazily on the first send, costing over a second inside the measured send path. Add warm_orchard_proving_key to testutils and await it with tokio::join! alongside CC::setup, so the key builds while the local network launches. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Add timed, a helper that logs a phase label and its elapsed wall-clock seconds around any future, and wrap the send_shield_cycle call graph with it: environment setup, client construction, chain-height increases, indexer convergence, wallet syncs, proposal and send steps, and each confirmation round. The test installs a tracing subscriber so the phase log reaches stdout. These timers produced the measurements behind the preceding speed-ups. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
Author
|
Test only PR, tested and benchmarked. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Profiling showed that zebra's getblocktemplate dominates this test. Each template builds a fresh shielded coinbase with a proof. An empty template costs about 2.2 seconds. A transaction-bearing template costs about 4.5 seconds.
This branch lands three speed-ups and the instrumentation that found them.
Zebrad::generate_blocksnow parks a long-poll getblocktemplate after each mined block. Zebrad precomputes the next coinbase during harness work. Mining drops from 28.3 to 23.2 seconds mean.follow_proposalraced the indexer with a baresync_and_await. The wasted confirm round cost about nine seconds.sync_client_to_tipbarriers on indexer convergence first.timedhelper logs each phase's label and elapsed seconds across the whole call graph. These timers produced the measurements above.The measured mean run time falls from 58.4 seconds to about 44 seconds. A run through the merged pin confirmed 45.6 seconds.
🤖 Generated with Claude Code