Measure a change.
Keep the context.
Use a repeatable record to compare your own PC before and after a setting change. This is an editorial test plan, not a report of Radiant performance results.
Keep every run together.
Download a CSV template for your test conditions, measurements and rollback notes. It contains empty rows, not sample FPS claims.
Download the worksheet ↓Write the question first
Make it specific: does one setting reduce a repeatable hitch in a particular scene without causing another problem? “Is my PC faster?” leaves too many variables open. A before/after comparison can describe an association; stronger causal confidence needs repeated controls and a baseline restored afterward.
Keep these conditions fixed
| Area | Record | Why it matters |
|---|---|---|
| Machine | CPU, GPU, memory, OS build and driver | Another machine’s result is not your starting point |
| Workload | Game/build, scene or replay, duration and resolution | Different work makes the averages difficult to compare |
| Rendering | Preset, frame cap, V-sync, scaling and frame generation | Keep reported metrics and rendering modes comparable |
| Session | Power mode, background tasks and temperature conditions | A background update or warm-up can affect a run |
| Change | One exact setting, original value and new value | You need an explanation and a way back |
A small repeatable protocol
- Warm up and record the baselineUse a repeatable built-in benchmark or saved scene where possible. Keep several runs; three is a practical starting point, not a statistical guarantee.
- Apply one understood changeLog it and its reversal method. Do not add another optimizer, new driver and new game preset between the two sets.
- Repeat the same workloadUse the same capture tool, metric definition and duration. Keep unsuccessful runs with notes instead of silently discarding them.
- Restore and recheckReturn to the initial setting and repeat the baseline. If it has drifted, investigate before crediting the setting.
Read more than average FPS
Keep individual runs visible and compare their spread. Include frame-time behavior or the capture tool’s consistently defined low-percentile metric, crashes, temperatures and any broken function. Do not mix different tools’ definitions of “1% low.” FPS alone is not a measurement of network ping or end-to-end input latency.
A small difference that sits within normal run-to-run variation is inconclusive. Even a repeatable gain in one scene should be described with the tested setup and limitations, rather than generalized to every game.
A useful conclusion has four parts
What changed; where you measured; what happened across runs; what you could restore. Include downsides and uncertainty. If a result is inconclusive, keeping the simpler starting setup is a reasonable outcome.
How this relates to our product guides
The publishers describe hardware-dependent results; our Radiant vs Hone guide compares published features and terms. This worksheet is our own suggested recording workflow. No software was installed or benchmarked to create it. Read the recovery and safety questions before making a system change.
Browser games
Browser games
Browser games