The problem with "forty percent faster"
A compatibility layer that runs a game at forty percent more frames per second than it did last month is a meaningful statement only if you know what last month's number was. Forty percent of twelve frames per second is still a slideshow. Forty percent of ninety is a genuinely good result. The percentage, standing alone, tells you nothing you can falsify.
This matters more in compatibility work than almost anywhere else, because the baseline shifts constantly. A driver update, a shader cache warm-up, a different kernel scheduler — any of these can move the denominator without anyone touching the layer itself. When a relative improvement is reported against an unstated, unreproducible baseline, the number is not wrong exactly; it is simply not checkable. Unfalsifiable numbers are not evidence.
The same trap appears at the other end of the scale. A layer described as adding "only five percent overhead" sounds acceptable until you learn that the test was run on a workload where the GPU was the bottleneck. If the CPU was idle, translation cost almost nothing — not because the layer is efficient, but because that test could not see it. The percentage is technically accurate and practically misleading. Where the milliseconds go is always the right question before you trust any overhead figure.
Percentages also obscure the shape of a distribution. A layer might deliver average frame times that are three percent slower than native, while its ninety-ninth-percentile frame time is forty percent worse. The average looks fine. The game feels bad. A single relative figure collapses that entire distribution into one number and discards everything that corresponds to perceived smoothness.
The fix is not to distrust relative numbers altogether — they carry real information when the base is stated, the workload is named, the hardware is specified, and the run was warm before measurement started. The discipline is to treat any percentage that arrives without those anchors the way you would treat a map with no scale bar: aesthetically plausible, practically useless.
Ask for the raw frame times. Ask which pass was measured. Ask what the denominator was and whether it was stable. A percentage that survives those questions is worth reading. Most do not survive them.
The three questions to surface
FROM THIS ENTRY| What was the raw base number? | |
|---|---|
| Was the run warm before measurement started? | |
| Was the bottleneck CPU or GPU during the test? |
Cedega is an independent publication about how compatibility layers work. It is not a software vendor, distributor, or support service.