Summary
Flagging for visibility — the exec3/remove-rwtx-threading-merge-main branch is ~34% slower than bal-devnet-3 on the SSTORE-bloated benchmark despite identical I/O profiles. Likely expected given the in-flight refactoring on that branch, but worth noting before any merge so the regression isn't lost.
Measurement
Same fixture (issue #20920 SSTORE-bloated test_sstore_bloated[10GB-fork_Osaka-NO_CACHE-existing_slots_True-write_new_value_True-30M], perf-devnet-3 block 24358306), same hardware (dev-bm-e3-ethmainnet-n4), same datadir master, no docker / no overlayfs, parallel exec engaged in both runs:
| Branch |
mgas/s |
wall |
bal-devnet-3 (26cd9a0) |
2.00 |
14.92s |
exec3/remove-rwtx-threading-merge-main (2a2667a) |
1.49 |
19.93s |
I/O is identical, delta is CPU-side
Per-mmap'd-file Rss deltas show the same dominant files in both runs (commitment .kvi + .kv, storage history .ef, latest storage .kv), with commitment file sizes essentially identical across branches:
| File |
rwtx Run |
bal-devnet-3 Run |
v2.0-commitment.7488-7492.kvi |
+306 MiB |
+299 MiB |
v2.0-commitment.7492-7494.kvi |
+188 MiB |
+182 MiB |
v2.0-storage.7488-7492.kv |
+152 MiB |
+152 MiB |
v2.0-commitment.7494-7495.kvi |
+128 MiB |
+118 MiB |
v2.0-commitment.7488-7492.kv |
+106 MiB |
+106 MiB |
Per-IOP size identical at ~4 KB. chaindata MDBX trivial in both. So the I/O work the trie does is unchanged; the wall-time delta is CPU.
Run data
/home/erigon/perf_results/sstore-bench/run-a-baseline-165007/ (exec3/remove-rwtx-threading-merge-main)/home/erigon/perf_results/sstore-bench/run-b-bal-devnet-3-172728/ (bal-devnet-3)
What this is / isn't
Likely expected given the parallel-exec refactoring in flight on exec3/remove-rwtx-threading-merge-main. Filing for visibility / future-merge attention rather than as an actionable defect. Not blocking.
Summary
Flagging for visibility — the
exec3/remove-rwtx-threading-merge-mainbranch is ~34% slower thanbal-devnet-3on the SSTORE-bloated benchmark despite identical I/O profiles. Likely expected given the in-flight refactoring on that branch, but worth noting before any merge so the regression isn't lost.Measurement
Same fixture (issue #20920 SSTORE-bloated
test_sstore_bloated[10GB-fork_Osaka-NO_CACHE-existing_slots_True-write_new_value_True-30M], perf-devnet-3 block 24358306), same hardware (dev-bm-e3-ethmainnet-n4), same datadir master, no docker / no overlayfs, parallel exec engaged in both runs:bal-devnet-3(26cd9a0)exec3/remove-rwtx-threading-merge-main(2a2667a)I/O is identical, delta is CPU-side
Per-mmap'd-file Rss deltas show the same dominant files in both runs (commitment
.kvi+.kv, storage history.ef, latest storage.kv), with commitment file sizes essentially identical across branches:v2.0-commitment.7488-7492.kviv2.0-commitment.7492-7494.kviv2.0-storage.7488-7492.kvv2.0-commitment.7494-7495.kviv2.0-commitment.7488-7492.kvPer-IOP size identical at ~4 KB. chaindata MDBX trivial in both. So the I/O work the trie does is unchanged; the wall-time delta is CPU.
Run data
/home/erigon/perf_results/sstore-bench/run-a-baseline-165007/(exec3/remove-rwtx-threading-merge-main)/home/erigon/perf_results/sstore-bench/run-b-bal-devnet-3-172728/(bal-devnet-3)What this is / isn't
Likely expected given the parallel-exec refactoring in flight on
exec3/remove-rwtx-threading-merge-main. Filing for visibility / future-merge attention rather than as an actionable defect. Not blocking.