-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Support running the pallet benchmarks analysis without running the benchmarks #12361
Support running the pallet benchmarks analysis without running the benchmarks #12361
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dont have suggestions about naming or anything like that, but yeah, like the feature
@ggwpez Applied your two suggestions; should be good to go! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works perfectly, thanks!
/cmd queue -c fmt $ 1 |
@ggwpez https://gitlab.parity.io/parity/mirrors/substrate/-/jobs/1892322 was started for your command Comment |
@ggwpez Command |
@ggwpez The zip file which the bot generated is empty; is this what you expected? (: |
bot merge |
That was just the formatting bot. No idea why it also produces empty zip files 🤷♂️ @koute |
This pull request has been mentioned on Polkadot Forum. There might be relevant details there: https://forum.polkadot.network/t/polkadot-release-analysis/1026/2 |
polkadot-developers/substrate-docs#1621 |
…nchmarks (paritytech#12361) * Support running the pallet benchmarks analysis without running the benchmarks * Rename `override-results` to `json-input` and update the help comment * ".git/.scripts/fmt.sh" 1 Co-authored-by: command-bot <>
This PR adds a new argument to the benchmarking CLI:
--json-input <path.json>
.The idea is: you run the benchmarks once and generate raw results with
--json-file
, and then you can rerun the analysis and regenerate the weights as many times as you want, without actually rerunning the benchmarks.This is in particular useful when working on the code responsible for the analysis since it makes it possible to do apples-to-apples comparisons while keeping the raw benchmark numbers constant.
Implementation notes
I've decided to just add an extra argument instead of a new command/subcommand since that seemed to be the least intrusive way to introduce this functionality, and there is already a precedent for it in the form of the
--list
argument; conceptually this might not be the cleanest, but should still be cheap to maintain and doesn't require rewriting half of the code.I'm also open to suggestions in case someone has a better name for the command line argument. (: