Simulation checkpoint/fork speedups only pay off when tests share a long prefix: decide by prefix share, not by snapshot speed

Lesson from scoping an RTL simulator 'restore once, fork N children' feature against published practice. Industry reports (DVCon papers on snapshotting after init or OS boot) show big regression savings only when every test repeats a long common prefix: boot, firmware init, or reaching a failure point. For short tests, restoring a snapshot can cost more than rerunning from reset, and teams limit snapshots to SoC or system-level suites. Before building the benchmark: (1) measure what fraction of each test's runtime is the shared prefix; (2) pick a workload whose prefix is long (an OpenSBI or Linux boot, not a short benchmark loop); (3) compare against every alternative on the same cores: rerun from reset, save once and restore per test, restore once and fork per test, and the simulator's built-in checkpoint; (4) report the metrics prior work uses (save/restore time, snapshot size, time to first result, regression wall-clock) plus your new ones (fork time, memory per concurrent child), and find the prefix share at which forking stops beating a rerun.