Sanity-check gtf opcodes
#1499
Assignees
Comments
xgreenx
added a commit
that referenced
this issue
Nov 22, 2023
#1499 vm benches: ``` gtf/gtf time: [208.43 ns 208.99 ns 209.60 ns] ``` sanity benches: ``` block target estimation/other/gtf time: [65.877 ms 66.094 ms 66.323 ms] ``` --------- Co-authored-by: xgreenx <[email protected]>
|
Closed by #1503 |
crypto523
pushed a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
FuelLabs/fuel-core#1499 vm benches: ``` gtf/gtf time: [208.43 ns 208.99 ns 209.60 ns] ``` sanity benches: ``` block target estimation/other/gtf time: [65.877 ms 66.094 ms 66.323 ms] ``` --------- Co-authored-by: xgreenx <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Following #1386
Might not need to create a benchmark for every
gtfopcode, but rather choose a good candidate for worst-case scenario.Specifically, the opcodes that get metadata from inputs/outputs can take longer if there are more inputs/outputs. We might be able to choose a worst-case opcode and overcharge for the others since
gtfisn't called many times in a single script.The text was updated successfully, but these errors were encountered: