chore(benchmarks): Rehauling Benchmark Workloads

[sw360cab]

Things changes

• using new action plugin: benchmark-action/github-action-benchmark
  • previous library was bobheadxi/gobenchdata
• creating alerts when benchmarks results are worse

Things unchanged

• Pushing benchmarks results onto a local branch, then benchmark repository will fetch from this into his own gh-pages
  • direct push is possible but requires PAT token to be used

Things TODO (before merging)

• restore benchmarks actions which were manually disabled directly in the Action menu in Github
• drop and recreate branch gh-repository
• fix benchmark tests in Gno repo (see Benchamark Test panicking for GnoVM #2711 and TM2 iavl BenchmarkLarge panicking #2714)
• Evaluate alternative configuration possibilities here

Things to consider (performance)

• Should solve [chain] Upload and display benchmarks for the gno monorepo #2432
• are resources available in the Github basic runners enough for benchmarks?
• are multiple runs spawned in the same hw conditions?
  • consider using Larger Runner or restoring a Self-Hosted Runner

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 60.82%. Comparing base (ca9eb4b) to head (ad27729).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2716      +/-   ##
==========================================
- Coverage   60.91%   60.82%   -0.09%     
==========================================
  Files         564      357     -207     
  Lines       75267    31871   -43396     
==========================================
- Hits        45849    19387   -26462     
+ Misses      26047    10695   -15352     
+ Partials     3371     1789    -1582     

Flag	Coverage Δ
contribs/gnodev	61.46% <ø> (ø)
contribs/gnofaucet	14.46% <ø> (ø)
contribs/gnokeykc	?
contribs/gnomd	?
gno.land	?
gno.land-_test.gnokey	?
gno.land-_test.gnoland	?
gno.land-_test.pkgs	?
gnovm	?
gnovm-_test.cmd	?
gnovm-_test.gnolang.native	?
gnovm-_test.gnolang.other	?
gnovm-_test.gnolang.pkg0	?
gnovm-_test.gnolang.pkg1	?
gnovm-_test.gnolang.pkg2	?
gnovm-_test.gnolang.realm	?
gnovm-_test.gnolang.stdlibs	?
gnovm-_test.pkg	?
go-1.21.x	?
go-1.22.x	?
misc	?
misc-_test.genstd	?
misc/autocounterd	?
misc/genproto	?
misc/genstd	80.54% <ø> (ø)
misc/goscan	?
misc/logos	19.88% <ø> (-0.36%)	⬇️
misc/loop	?
tm2	62.09% <ø> (+0.01%)	⬆️
tm2-_test.flappy	?
tm2-_test.pkg.amino	?
tm2-_test.pkg.bft	?
tm2-_test.pkg.others	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sw360cab]

cc @ajnavarro

[ajnavarro]

@sw360cab answering your questions:

Should solve #2432

I think so.

Are resources available in the GitHub basic runners enough for benchmarks?

Github basic runners AFAIK are virtual machines sharing resources with other runs. From my experience, if we use GitHub default runners, historical benchmark data won't be useful, because it will be inaccurate (sometimes being faster than others, not knowing if it was for something we improved in our codebase, or because the GitHub node was overloaded that run).

Having the same hardware always for benchmarks will also help a ton to compare performance improvements realistically.

are multiple runs spawned in the same hw conditions?

If I understood correctly, I think we should only run one benchmark job at a time.

[sw360cab]

TODO: get back README in .becnhmarks folder and adjust its content.

[zivkovicmilos]

Thank you for fixing this 🙏

[thehowl]

Just checked the bugs you mentioned; made a patch for the first one. The second one's solution is likely just to skip boltdb in testing.

[sw360cab]

Close #2432