[mono-move] Small benchmark improvements

[georgemitenkov]

Description

Ability to benchmark 1 VM at a time via --vm (both } v1 | v2) flags.

How Has This Been Tested?

Key Areas to Review

Type of Change

• New feature
• Bug fix
• Breaking change
• Performance improvement
• Refactoring
• Dependency update
• Documentation update
• Tests

Which Components or Systems Does This Change Impact?

• Validator Node
• Full Node (API, Indexer, etc.)
• Move/Aptos Virtual Machine
• Aptos Framework
• Aptos CLI/SDK
• Developer Infrastructure
• Move Compiler
• Other (specify)

Checklist

• I have read and followed the CONTRIBUTING doc
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I identified and added all stakeholders and component owners affected by this change as reviewers
• I tested both happy and unhappy path of the functionality
• I have made corresponding changes to the documentation

---

Note

Low Risk
Changes are limited to the mono-move replay-benchmark developer tool and default behavior remains both VMs; no validator or production VM paths are affected.

Overview
Adds a --vm CLI option (v1, v2, or both, default both) so the replay benchmark can run only the legacy Move VM or only MonoMove—useful for profiling one VM without the other in the same process.

Reporting now treats each VM result as optional: skipped VMs print as skipped, and speedup/correctness lines are omitted unless both VMs ran.

The README documents benchmarking a single transaction via --transactions-file / --inputs-file and gives a samply example with --vm v1. Two TODO comments in the V2 harness flag possible missing reset of events/extensions between timed iterations (no behavior change in this PR).

^{Reviewed by Cursor Bugbot for commit abac4eb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[georgemitenkov]

• [mono-move] Small benchmark improvements #20158 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

mono-move benchmark gate

1 regression(s) beyond ±3% noise band

4 ok · 2 improved · 0 new · 0 absent (threshold T = ±3%, criterion mean CI vs main)

Benchmark	mean Δ	95% CI	median (main → PR)	Verdict
fib/mono	-4.8%	[-5.1%, -4.6%]	9.74ms → 9.30ms	improved
nested_loop/mono	-4.3%	[-4.8%, -3.8%]	17.37ms → 16.62ms	improved
merge_sort/mono	+1.1%	[+0.6%, +1.5%]	1.43ms → 1.45ms	ok
bst/mono	-3.6%	[-4.8%, -2.6%]	4.37ms → 4.25ms	ok
match_sum/mono	+11.4%	[+10.4%, +12.4%]	29.53ms → 32.89ms	regression
int_arith_loop/mono_u64	-2.3%	[-2.8%, -1.7%]	449.85µs → 433.42µs	ok
int_arith_loop/mono_i64	-2.4%	[-2.9%, -1.8%]	679.44µs → 656.17µs	ok

Improvements are not failures. main rebaselines on merge, so the next PR compares against the faster code automatically.