Run comparison

Open BoosterX → Benchmark → Comparison and add the saved results you need. For a before/after experiment, choose the same load version, profile and conditions. A difference in numbers by itself does not prove the effect of a tweak.

In the interface you can study the differences between different runs as well: CPU, GPU, latencies, absolute values and percentages. Mismatched conditions do not make the numbers themselves useless, but they limit the conclusion about the cause of the difference. Check the compatibility warnings and do not treat a comparison of different versions as a clean experiment.

Scores may be recalculated according to the current server-side formula, so compare the scores of one methodology and the raw metrics separately. Recalculation does not change the load that was performed. A place in the single online leaderboard is not proof of identical measurement conditions.

Experiment plan

1. Record the CPU and GPU model, Windows and driver versions. Do not change the power mode or cooling between tests. Use the same set of background programs.
2. First run at least three tests without changing any settings. This way you will see the normal spread of results. A conclusion about small differences may require more repetitions.
3. Change one setting and repeat the tests. If a reboot is required, perform it before the baseline series as well. Before each run, wait the same amount of time.
4. If possible, check the baseline settings, then the changed ones, and then the baseline again: A → B → A. Such a sequence helps separate the effect of the tweak from warm-up and background load.
5. Save all results. Determine in advance which failures make a test unsuitable for comparison, for example an interrupted run. If you exclude a test, state the reason. A low score by itself is not a reason to delete it.

Keep the screen resolution and the windowed or fullscreen mode the same. If you are testing the effect of resolution, repeat the test several times at each chosen resolution.

What to count

Δ score, % = 100 × (mean_after / mean_before − 1)
CV, % = 100 × sample_standard_deviation / mean

Compare the mean values and the spread between runs. Check not only the final score, but also the individual scores, latencies in milliseconds, P99 / 1% Low CPU and the throughput of each load. For latencies, a negative difference usually means an improvement; for scores, a positive difference means a higher score.

To check repeatability, count full runs. Thousands of frames within a single test do not replace repeated tests: they are all obtained in one session and depend on shared conditions.

What can be concluded

A small change relative to the normal spread requires additional repetitions. A universal threshold like “anything above 1% is significant” cannot be established from a single series. Even a statistically distinguishable difference may be too small for a practical effect.

Block-by-block diagnostics are already built into the results: for each load, the spread of throughput across blocks, the first-to-last shift and the trend across steps are saved. This allows you to judge whether the difference between two runs exceeds the noise observed within them, even before new repetitions. The formulas by which blocks are aggregated into scores are open in the score calculation.

The archived series of eight runs of version 0.5.2 compared repetitions and resolutions on an optimized system. It does not contain an unoptimized state and therefore does not prove a gain from BoosterX.

A synthetic test helps investigate changes in system behavior. To verify the benefit for a specific game, repeat the comparison in its reproducible game scenario.

Updated: 2026-10-02.