bug(reexecution/c): incorrect github-action-runner data points

[RodrigoVillar]

Currently, the github-action-benchmark (GAB) dashboard is flawed as it's displaying incorrect data points as seen below:

This bug is a result of #4369, which added additional metrics besides the top-level mgas/s. During debugging, what I found interesting is that mgas/s is correctly being parsed by GAB as seen here:

avalanchego/dev/bench/data.js

Lines 1083 to 1119 in 63cf7b8

	"benches": [
	{
	"name": "BenchmarkReexecuteRange/[33000001,33500000]-Config-default-Runner-avago-runner-m6i-4xlarge-ebs-fast",
	"value": 51.54,
	"unit": "block_accept_ms/ggas\t 67.61 block_parse_ms/ggas\t 22961 block_verify_ms/ggas\t 43.32 mgas/s\t 23083 ms/ggas",
	"extra": "1 times\n16 procs"
	},
	{
	"name": "BenchmarkReexecuteRange/[33000001,33500000]-Config-default-Runner-avago-runner-m6i-4xlarge-ebs-fast - block_accept_ms/ggas",
	"value": 51.54,
	"unit": "block_accept_ms/ggas",
	"extra": "1 times\n16 procs"
	},
	{
	"name": "BenchmarkReexecuteRange/[33000001,33500000]-Config-default-Runner-avago-runner-m6i-4xlarge-ebs-fast - block_parse_ms/ggas",
	"value": 67.61,
	"unit": "block_parse_ms/ggas",
	"extra": "1 times\n16 procs"
	},
	{
	"name": "BenchmarkReexecuteRange/[33000001,33500000]-Config-default-Runner-avago-runner-m6i-4xlarge-ebs-fast - block_verify_ms/ggas",
	"value": 22961,
	"unit": "block_verify_ms/ggas",
	"extra": "1 times\n16 procs"
	},
	{
	"name": "BenchmarkReexecuteRange/[33000001,33500000]-Config-default-Runner-avago-runner-m6i-4xlarge-ebs-fast - mgas/s",
	"value": 43.32,
	"unit": "mgas/s",
	"extra": "1 times\n16 procs"
	},
	{
	"name": "BenchmarkReexecuteRange/[33000001,33500000]-Config-default-Runner-avago-runner-m6i-4xlarge-ebs-fast - ms/ggas",
	"value": 23083,
	"unit": "ms/ggas",
	"extra": "1 times\n16 procs"
	}

Scrolling down https://ava-labs.github.io/avalanchego/dev/bench/ reveals that mgas/s is correctly being parsed.
For some reason though, GAB is also parsing an additional garbage metric with unit block_accept_ms/ggas\t 67.61 block_parse_ms/ggas\t 22961 block_verify_ms/ggas\t 43.32 mgas/s\t 23083 ms/ggas and creating a dashboard for it under mgas/s, which led to the initial confusion.

Looking at the GAB for how go bench outputs are parsed, I noticed the following:

https://github.com/benchmark-action/github-action-benchmark/blob/2e6f4e33d6695578ee68981a04100aa77e0ac037/src/extract.ts#L373-L375

It seems that this code is what is creating the garbage metric and perhaps resulting in the dashboard seen in the image above.

Next Steps

Outlined are several possible solutions:

• Making a PR to GAB and hoping it get's merged in
  • Not in our control
  • We should make an issue nonetheless
• Refactoring our benchmark code to not use go bench
  • At the end of a test run, instead of piping go bench ... to a file, we would instead construct the benchmark data manually (which is mentioned here) and send that to GAB. Since we're constructing the benchmark data, we won't run into the issue of having garbage metrics.
  • Comes with the benefit of removing go bench from the reexecution code, which is not currently being used as intended.