Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve existing full block benchmark #2168

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

JamesHinshelwood
Copy link
Contributor

Previously we would generate pre-emptively generate 3.2 million transactions, just in case we ran enough iterations to need them. Instead, we use Criterion's iter_batched method to generate the transactions as they are needed. This ensures we don't generate more transactions than we need and that we don't consume loads of memory. The two downsides of this approach are:

  • We don't generate transactions in parallel any more, but this doesn't seem to make much difference to the total benchmarking time now that we aren't over-generating transactions.
  • The generated flamegraphs now include the transaction generation calls, but drilling down and ignoring them is only one keypress.

I've also renamed the benchmark from produce-full to full-blocks-evm-transfers since I think it better represents what we are testing.

Copy link
Contributor

github-actions bot commented Jan 17, 2025

🐰 Bencher Report

Branchimprove-bench
Testbedself-hosted
Click to view all benchmark results
BenchmarkLatencyBenchmark Result
milliseconds (ms)
(Result Δ%)
Upper Boundary
milliseconds (ms)
(Limit %)
full-blocks-evm-transfers/full-blocks-evm-transfers📈 view plot
🚷 view threshold
803.02
process-empty/process-empty📈 view plot
🚷 view threshold
8.48
(-7.30%)
10.41
(81.43%)
🐰 View full continuous benchmarking report in Bencher

Previously we would generate pre-emptively generate 3.2 million
transactions, just in case we ran enough iterations to need them.
Instead, we use Criterion's `iter_batched` method to generate the
transactions as they are needed. This ensures we don't generate
more transactions than we need and that we don't consume loads of
memory. The two downsides of this approach are:

* We don't generate transactions in parallel any more, but this
doesn't seem to make much difference to the total benchmarking
time now that we aren't over-generating transactions.
* The generated flamegraphs now include the transaction generation
calls, but drilling down and ignoring them is only one keypress.

I've also renamed the benchmark from `produce-full` to
`full-blocks-evm-transfers` since I think it better represents
what we are testing.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant