Add benchmark your pallet #1189
Open
Conversation
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
brunopgalvao
added
B0 - Needs Review
brunopgalvao
had a problem deploying
to
n8n-sending
GitHub Actions
Failure
nhussein11
approved these changes
Nov 11, 2025
Collaborator
nhussein11
left a comment
nhussein11
left a comment
There was a problem hiding this comment.
Interesting read, thank you!
| Benchmarking is a critical component of developing efficient and secure blockchain runtimes. In the Polkadot ecosystem, accurately benchmarking your custom pallets ensures that each extrinsic has a precise [weight](/reference/glossary/#weight){target=\_blank}, representing its computational and storage demands. This process is vital for maintaining the blockchain's performance and preventing potential vulnerabilities, such as Denial of Service (DoS) attacks. | ||
| Benchmarking is the process of measuring the computational resources (execution time and storage) required by your pallet's extrinsics. Accurate [weight](https://paritytech.github.io/polkadot-sdk/master/frame_support/weights/index.html){target=\_blank} calculations are essential for ensuring your blockchain can process transactions efficiently while protecting against denial-of-service attacks. | ||
|
|
||
| This guide continues the pallet development series, building on the [Create a Pallet](/parachains/customize-runtime/pallet-development/create-a-pallet), [Mock Your Runtime](/parachains/customize-runtime/pallet-development/mock-runtime), and [Test Your Pallet](/parachains/customize-runtime/pallet-development/pallet-testing) tutorials. You'll learn how to benchmark the counter pallet extrinsics and integrate the generated weights into your runtime. |
Collaborator
There was a problem hiding this comment.
This links should have {target=\_blank}
| Before you begin, ensure you have: | ||
|
|
||
| - Completed the previous pallet development tutorials | ||
| - Basic understanding of computational complexity |
Collaborator
There was a problem hiding this comment.
Maybe add a link for computational complexity if readers aren't familiar with it. For example:
"basic understanding of computational complexity (check this [page] to understand what is it)"
| - Basic understanding of computational complexity | ||
| - Familiarity with Rust's testing framework | ||
|
|
||
| ## Why Benchmark? |
Collaborator
There was a problem hiding this comment.
I recall that regulators tend to avoid using question titles whenever possible.
| - [`ref_time`](https://paritytech.github.io/polkadot-sdk/master/frame_support/weights/struct.Weight.html#method.ref_time){target=\_blank}: Computational time measured in picoseconds | ||
| - [`proof_size`](https://paritytech.github.io/polkadot-sdk/master/frame_support/weights/struct.Weight.html#method.proof_size){target=\_blank}: Storage proof size in bytes | ||
|
|
||
| ## Step 1: Create the Benchmarking Module |
Collaborator
There was a problem hiding this comment.
And I believe that we don't use this kind of titles with steps, we should do: "## Create the Benchmarking Module"
|
|
||
| ## Step 3: Add WeightInfo to Config | ||
|
|
||
| By making `WeightInfo` an associated type in the `Config` trait, you allow each runtime that uses your pallet to specify which weight implementation to use. Different deployment environments (testnets, production chains, or different hardware configurations) may have different performance characteristics and can use different weight calculations. |
Collaborator
There was a problem hiding this comment.
Suggested change
| By making `WeightInfo` an associated type in the `Config` trait, you allow each runtime that uses your pallet to specify which weight implementation to use. Different deployment environments (testnets, production chains, or different hardware configurations) may have different performance characteristics and can use different weight calculations. | |
| By making `WeightInfo` an associated type in the `Config` trait, you allow each runtime that uses your pallet to specify which weight implementation to use. Different deployment environments (TestNets, production chains, or different hardware configurations) may have different performance characteristics and can use different weight calculations. |
|
|
||
| ## Step 5: Include the Benchmarking Module | ||
|
|
||
| The `#[cfg(feature = "runtime-benchmarks")]` attribute ensures that benchmarking code is only compiled when explicitly needed. This keeps your production runtime lean by excluding benchmarking infrastructure from normal builds, as it's only needed when generating weights. |
Collaborator
There was a problem hiding this comment.
Did you mean to say: "This keeps your production runtime Clean"? or "lean" was the correct word?
| ### Register Benchmarks | ||
|
|
||
| ## Benchmarking Process | ||
| The `define_benchmarks!` macro creates the infrastructure that allows the benchmarking CLI tool to discover and execute your pallet's benchmarks. |
Collaborator
There was a problem hiding this comment.
Suggested change
| The `define_benchmarks!` macro creates the infrastructure that allows the benchmarking CLI tool to discover and execute your pallet's benchmarks. | |
| The [`define_benchmarks!`](https://paritytech.github.io/polkadot-sdk/master/frame_benchmarking/macro.define_benchmarks.html){target=\_blank} macro creates the infrastructure that allows the benchmarking CLI tool to discover and execute your pallet's benchmarks. |
|
|
||
| Benchmarking on faster hardware than production leads to under-estimated weights - attackers could submit extrinsics that consume more resources than the weights suggest, potentially causing blocks to take longer than expected to produce or even halting the chain. Conversely, benchmarking on slower hardware creates over-estimated weights, resulting in unnecessarily high transaction fees and wasted block capacity. | ||
|
|
||
| **Best practices:** |
Collaborator
There was a problem hiding this comment.
I'd remove best practices
| **Note**: The actual numbers will vary based on your hardware and implementation complexity. The [`DbWeight`](https://paritytech.github.io/polkadot-sdk/master/frame_support/weights/struct.RuntimeDbWeight.html){target=\_blank} accounts for database read and write operations. | ||
|
|
||
| 2. Check your runtime's `lib.rs` file to ensure the `benchmarks` module is imported. The import should look like this: | ||
| ## Benchmarking Best Practices |
Collaborator
There was a problem hiding this comment.
I'd remove best practices
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
📝 Description
Resolves #1085
🔍 Review Preference
Choose one:
🤖 AI-Ready Docs
If content changed, regenerate AI files:
python3 scripts/generate_llms.py✅ Checklist