Define the question
Ask whether one specified change improves one specified workload on one machine. Keep the claim that narrow. A result in one game is not evidence for every game or every PC.
The protocol below is our proposed measurement method. Independent Windows testing has not yet been completed, and this page contains no measured results.
Record the test environment
Use the blank testing worksheet to keep conditions, individual runs and stability notes together. After capturing your results, use the FPS comparison tool to summarize entered values; it does not run a benchmark or replace the raw data.
Keep a record of CPU, GPU, RAM capacity and configuration, storage, Windows build, GPU driver, game version, optimization software version, display resolution, graphics settings, and the exact optimization applied.
Also record the test scene, capture duration, temperature conditions, power mode, and relevant background applications. Pick one measurement tool and record its version and metric definitions. Different tools may calculate low-percentile metrics differently.
Establish repeated baseline runs
- Select a built-in benchmark or a repeatable offline scene where possible.
- Warm up the workload first; avoid comparing a cold shader-compilation run with a warmed-up run.
- Capture at least three baseline runs using the same route and duration.
- Save the raw capture data and record any unusual event.
A live multiplayer match is difficult to repeat exactly. If that is your only option, report the limitation rather than presenting it as a controlled experiment.
Apply one change and repeat
Apply one documented optimization, follow its restart requirement, and capture at least three more runs under matching conditions. Keep the game settings and driver fixed.
When practical, reverse the change and repeat a baseline run to check for drift. If restoring the baseline is not possible, explain that limitation alongside the result.
Compare the right metrics
| Metric | What it helps describe | Interpretation limit |
|---|---|---|
| Average FPS | Overall throughput during the capture | Can hide short stalls |
| 1% low | Slow-frame behavior under the tool’s definition | Definitions differ between tools |
| Frame-time trace | Timing variation and individual spikes | Needs a matching scene and duration |
| Stability notes | Crashes and functional regressions | A short test cannot prove long-term reliability |
Report the individual runs and their spread. For average FPS, a simple percentage change is (after − before) / before × 100, provided the baseline is positive. Always state which summary statistic you used.
Publish the limits
If a change is smaller than run-to-run variation, call it inconclusive. Include unchanged and worse results alongside improvements. Do not select only the most favorable run.
Input latency requires a suitable measurement method. FPS alone is not a measurement of click-to-display latency. Do not infer an input-latency percentage from an FPS difference.
Our future reviews will include test conditions, raw-data references where available, repetitions, version dates, and limitations. Until those tests exist, this site publishes guidance rather than a performance verdict.