Use this worksheet to document one proposed change on one computer. It starts with three baseline rows and three after-change rows; the result fields are empty. It is a recording template, not a benchmark, an installer or evidence that any optimization works.
Download the blank worksheet
Download the CSV worksheet. Open it in a spreadsheet editor or a text editor. Keep an untouched copy and save a separate copy for each experiment. The file does not contain macros or executable code.
Three runs per condition are a starting point, not a guarantee of reliable conclusions. Add more rows if your scene varies substantially. Collect comparable runs for both conditions; do not keep only the best capture.
Before the first capture
Record the CPU, GPU, memory capacity, Windows build, GPU driver, game and game version, and the measurement tool with its version. Also record the resolution, graphics preset, scene or route, and capture duration in seconds. Use the same environment for the baseline and after-change captures.
The change_applied column identifies exactly what differs between conditions. In baseline rows, describe the original configuration. In after-change rows, name the one setting changed and any restart required. Keep screenshots of the original value and the documented reversal instructions with your notes.
Warm up the scene before recording. Avoid comparing a cold shader-compilation run with a warmed-up run. A live multiplayer match is difficult to reproduce; note that limitation if you cannot use a built-in benchmark or a repeatable offline scene. Read the full testing method before making changes.
Record each run separately
| Field | What to record |
|---|---|
phase, run | Baseline or after-change condition and the run number |
average_fps | The measurement tool’s average FPS for that run |
one_percent_low_fps | The tool’s reported 1% low FPS, if available; definitions differ by tool |
max_temperature_c | Optional peak temperature in Celsius; identify the sensor in your notes |
stability_notes | Crashes, stutters, audio/network problems, unusual background activity or incomplete captures |
raw_capture_filename | The saved capture filename so the summary can be checked against the original data |
Leave unavailable fields blank. Do not enter zero as a substitute for an unknown FPS value. Save raw captures even if a run looks unusual; explain any exclusion rather than deleting inconvenient results.
Compare without losing the evidence
Copy the per-run average FPS values into the FPS comparison tool, then optionally enter each run’s reported 1% low FPS. Keep the two metrics separate. The tool summarizes the entered runs and their spread; it does not reconstruct frame-time traces or recalculate a 1% percentile from raw frames.
Read the individual results before interpreting the percentage change. Overlapping ranges, changing temperatures or inconsistent scenes can make a small apparent improvement inconclusive. Even non-overlapping ranges do not establish causation or statistical significance on their own.
Keep a recovery and publication record
Write down whether ordinary use still works: game launch, networking, audio, peripherals and sleep. If the change causes a regression, follow its documented reversal and use troubleshooting to isolate the problem. A higher FPS result does not outweigh a stability problem.
When sharing results, include the conditions, each run, capture files where appropriate, excluded runs and the limits of the experiment. Check your files for personal information before making them public. Your completed worksheet stays on your device unless you choose to share it; downloading the blank template does not send us your completed results.