db/state, txpool: benchmark fixes and bench flag improvements#19971
Merged
AskAlexSharov merged 4 commits intomainfrom Mar 20, 2026
Merged
db/state, txpool: benchmark fixes and bench flag improvements#19971AskAlexSharov merged 4 commits intomainfrom
AskAlexSharov merged 4 commits intomainfrom
Conversation
…location b.Loop() manages iteration internally but b.N reflects the pre-allocated slice size. Using b.Loop() with b.N-based pre-allocation causes a panic when b.Loop() runs more iterations than b.N. Switch to the standard i < b.N loop so iteration count matches pre-allocation.
anacrolix
requested review from
AskAlexSharov,
sudeepdino008,
taratorio and
yperbasis
as code owners
yperbasis
approved these changes
Mar 18, 2026
Member
yperbasis
left a comment
yperbasis
left a comment
There was a problem hiding this comment.
One stale reference
Line 552 in BenchmarkDb_BeginFiles_Throughput_IO still has:
//b.Logf("Running with parallel=%d work=%d, #goroutines:%d", *parallel, *loopv, ...)
The PR updates the identical commented-out line in the other two benchmarks but misses this one. Not a build break (it's a comment), just inconsistent. Should be *sleepMs to match.
AskAlexSharov
approved these changes
Mar 19, 2026
anacrolix
added a commit
that referenced
this pull request
Mar 22, 2026
Two independent benchmark fixes. **`BenchmarkProcessRemoteTxns` panic**: mixed `b.Loop()` (Go 1.24+ API) for the benchmark loop with `b.N`-based pre-allocation for test data. On the first `runN` call `b.N=1`, so only 1 transaction is pre-created, then `b.Loop()` tries a second iteration and panics with `slice bounds out of range [:2] with capacity 1`. Fixed by switching back to `for i := 0; i < b.N; i++`. **`bench.loopv` split**: the shared flag was used in two benchmarks with semantically different meanings — CPU loop iterations in one, milliseconds of sleep in the other. These don't line up in magnitude: a value that makes sense for one (e.g. `100000` CPU iterations ≈ fast) is catastrophic for the other (`100000 ms = 100 seconds` sleep per iteration). With the default of `100000`, `BenchmarkDb_BeginFiles_Throughput` slept 100 seconds per iteration, completing only 1 iteration in a 112-second run. Split into `bench.cpu-iters` (default 1000) and `bench.sleep-ms` (default 5ms, matching the hardcoded value in `BenchmarkDb_BeginFiles_Throughput_IO`). --------- Co-authored-by: Alex Sharov <AskAlexSharov@gmail.com>
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
3 participants
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.
Two independent benchmark fixes.
BenchmarkProcessRemoteTxnspanic: mixedb.Loop()(Go 1.24+ API) for the benchmark loop withb.N-based pre-allocation for test data. On the firstrunNcallb.N=1, so only 1 transaction is pre-created, thenb.Loop()tries a second iteration and panics withslice bounds out of range [:2] with capacity 1. Fixed by switching back tofor i := 0; i < b.N; i++.bench.loopvsplit: the shared flag was used in two benchmarks with semantically different meanings — CPU loop iterations in one, milliseconds of sleep in the other. These don't line up in magnitude: a value that makes sense for one (e.g.100000CPU iterations ≈ fast) is catastrophic for the other (100000 ms = 100 secondssleep per iteration). With the default of100000,BenchmarkDb_BeginFiles_Throughputslept 100 seconds per iteration, completing only 1 iteration in a 112-second run. Split intobench.cpu-iters(default 1000) andbench.sleep-ms(default 5ms, matching the hardcoded value inBenchmarkDb_BeginFiles_Throughput_IO).