How many frames does Denuvo actually cost? We ran six games twice
Same machine, same save, same graphics settings, only the executable changed. The result sits closer to what players feel than to what publishers claim.
Both claims have believers: that Denuvo does not affect performance, and that installing it makes everything stutter. The evidence each side brings rarely lines up. Publishers quote average frame rate, players quote how it feels, and frame rate is a distribution rather than a number. An average cannot explain a problem in the tail of that distribution, so the argument never resolves.
We tried a different approach: change one variable.
How we tested
Six games with Denuvo, each with two executable versions. One is the encrypted build on sale, the other a DRM-free build the publisher later released. Everything else was locked: same machine, same save file, same three-minute route (a cutscene, a fight, a stretch of open-world traversal), same graphics settings.
The key choice was 1080p at the lowest preset. That takes the GPU out of the bottleneck and exposes the CPU's single-thread cost directly in frame times. Denuvo's checks are periodic CPU-side work. A GPU-bound run hides them; a CPU-bound run does not.
Each game ran three times, forward then backward then forward again, and we took the median. Capture was PresentMon, frame times only, no in-game counters.
Results: averages look fine, the tail does not
Average frame rate fell between 1.8% and 4.2% across the six games. At that size, "no performance impact" is a fair description. The publishers are not lying.
Split the distribution and the picture changes.
| Metric | No DRM | With Denuvo | Change |
|---|---|---|---|
| Average fps | baseline | -1.8% to -4.2% | barely visible |
| 1% low | baseline | -8% to -19% | visible |
| 0.1% low | baseline | down to -26% | severe |
| Frame time std dev | baseline | +31% | visible |
A 3% drop in average frame rate is invisible. A 26% drop at the 0.1% low is not. That is one frame stretching from 8 ms to 30 ms each time a check fires. Twice a second reads as stutter.
The same data as the table, drawn to scale. Bar length is the size of the change, and every one of them is worse for the player.
It also explains why ten years of argument produced no agreement. Run a benchmark and watch the average, and the answer is fine. Chase a monster across an open world, and the answer is unplayable. Both measurements describe different slices of the same thing.
Where it hurts most
The cost is not evenly distributed. Three situations amplify it.
CPU single-thread pressure. Old platforms, low presets and high refresh targets, especially together. The same game at 4K on a high preset converges to within 2%, because it is waiting on the GPU.
Open-world streaming. The encryption check and the streaming load land on the same frame, and that frame runs long.
Dense combat effects. This one needs no explanation.
On the other side: if your setup is 4K on a high preset already sitting just above 60 fps, you will probably never notice Denuvo.
Our threshold
We do not judge by average frame rate. We look at the drop in the 1% low and the change in frame time standard deviation.
Our current limit is a 1% low drop within 10% and a standard deviation increase within 20%. Past that, the game page marks "DRM overhead noticeable" and adds a separate row to the tested matrix.
One limit on this test: it covers performance only. It says nothing about Denuvo's other problems, such as offline activation, re-verification after a hardware change, or whether a game still runs once the publisher shuts down the licence server. Those are availability issues, and they matter more than frame rate, but they sit outside this piece.
One line for publishers: if encryption really costs 3%, ship the DRM-free build alongside it and let people compare. Refusing to is its own answer.
