[autoopt] 20260414-011-save-blocks-cursor-reuse

[mediocregopher]

Reuse save_blocks MDBX cursors across block batches

Evidence

• artifacts/24407188705/bench-reth-results/summary.json shows persistence wait dominating end-to-end latency at 29.57 ms mean / 265.62 ms p95.
• The baseline-1 samply profile shows the persistence thread at 297,408 samples, with PersistenceService::on_save_blocks -> DatabaseProvider::save_blocks accounting for 293,897 inclusive samples.
• In crates/storage/provider/src/providers/database/provider.rs, the hot save_blocks() loop reopened append-only MDBX cursors for TransactionSenders, BlockBodyIndices, and TransactionBlocks on every block even though the whole batch is already ordered and written inside one transaction.
• This stays clear of the previously rejected "batch save_blocks writes by table" direction by preserving the existing per-block write order and only removing repeated cursor-open overhead.

Hypothesis

If we reuse the append-only MDBX cursors across the whole save_blocks() batch, gas throughput improves by ~0.2-0.6% because persistence avoids reopening the same write cursors for every block in the hottest disk-bound path.

Success Metric

• gas_per_second (mgas_s.pct in summary.json) improves by >0.2%

Plan

• Open the MDBX sender/body-index/tx-block cursors once in save_blocks() and thread them through the existing helper calls.
• Keep the current write order and table contents identical.
• Verify with cargo check -p reth-provider and cargo test -p reth-provider test_save_blocks_v2_table_assertions --lib.

[mediocregopher]

derek bench

[github-actions]

Your PR title doesn't follow the Conventional Commit guidelines.

Example of valid titles:

• feat: add new user login
• fix: correct button size
• docs: update README

Usage:

• feat: Introduces a new feature
• fix: Patches a bug
• chore: General maintenance tasks or updates
• test: Adding new tests or modifying existing tests
• bench: Adding new benchmarks or modifying existing benchmarks
• perf: Performance improvements
• refactor: Changes to improve code structure
• docs: Documentation updates
• ci: Changes to CI/CD configurations
• revert: Reverts a previously merged PR
• deps: Updates dependencies

Breaking Changes

Breaking changes are noted by using an exclamation mark. For example:

• feat!: changed the API
• chore(node)!: Removed unused public function

Help

For more information, follow the guidelines here: https://www.conventionalcommits.org/en/v1.0.0/

[decofe]

cc @mediocregopher

❌ Benchmark failed while unknown step. View logs