Performance testing guides

Measure an outcome before declaring an improvement

Performance testing needs a specific task and an explicit trade-off. Total completion time, request latency, interactive responsiveness, and reliability can point in different directions. Choose the outcome that matters to the workload owner, then retain supporting resource measurements to explain the result.

This collection applies that method to swappiness, compressed memory, AI offloading, and desktop diagnosis. The mechanisms differ, but each article asks for comparable inputs, one changed variable, and a baseline that exposes ordinary variation. A more attractive memory graph is not a substitute for better useful work.

The Desktop Memory Swap guide is a good practical entry point. AI readers should use the VRAM guide to separate model loading from realistic inference. Linux readers can compare policy only after identifying the current backing arrangement.

Include costs and regressions in the record. A configuration might preserve interactivity by making a background job longer, or fit a model by adding transfer delays. Those can be legitimate choices when documented. They should not be described as universal speed improvements detached from the test conditions.