megadev-performance
Measure Megadev performance
Start with a repeatable workload, a correctness check and one suspected bottleneck. Preserve the exact build, region/video target, assets and input configuration. Use ewrogers/megadev:latest, retain doctor output and inspect the selected SDK sources before teaching a timing API. Read Megadev timing integration for verified facilities and shared-resource constraints.
Say what a measurement means
Use measurement contracts to distinguish a completed batch, elapsed stopwatch ticks, serviced VBlanks, observed request latency, completed uploads and CPU utilization. None is interchangeable. A busy pipeline or a long wait is not proof that a CPU is executing useful work.
Keep interrupt/CD/audio service enabled unless an isolated measurement specifically requires otherwise. Report interruptions and sampling overhead. Do not reset a shared stopwatch, install a second frame/transfer owner, silently drop long samples or call emulator instruction counts hardware cycles.
Compare one change at a time
Read controlled experiments for warm-up, fixed inputs, observer-cost checks and region comparisons. Verify equivalent output before accepting an optimization. Check several trials, worst observed cases and the release build. Preserve a slow reference/oracle for tests; do not make production execute it inside every timed batch.
Performance Lab compares remainder versus incremental wrapping, resident VRAM uploads, the real graphics ASIC pipeline and combined Main/ASIC/VRAM work. It provides HUD/timer toggles and drains leases before changing cases. Its live counters are not a console-wide CPU meter or a maximum-bandwidth certification.
Use the comparison tool to normalize completed run counters over their actual reported window. It rejects failed/incomplete runs and changes along more than one declared configuration axis. It processes recorded numbers; it does not capture ares or prove where those numbers came from.