Performance conversations around anti-piracy often get reduced to a simple claim: code was added and obfuscated, so performance must have suffered. That framing is easy to understand, but it misses how game performance works in practice.
In a shipped game, the impact visible to players depends on when and where those functions execute and which thread they run on.
This is why anti-piracy performance is best understood as an integration and runtime-execution question.
Studios build games in source code, but the version delivered to players is the compiled game binary, typically across EXE/DLLs. Many systems operate together in that shipped runtime, including gameplay systems, audio, platform APIs (for example, Steam APIs), telemetry, middleware and anti-piracy protection.
The shipped binary is not just “gameplay code.” It is the runtime environment where these systems operate together.
Once you look at the game this way, one distinction becomes especially important:
In simple terms, functions help define what work is happening, and threads help determine when and where that work is carried out at runtime.
Here is a simple truth: gameplay impact is shaped less by the presence of protection and more by where it is placed and how it executes.
The reason is straightforward. Protection is typically a very small part of the overall game binary, often around 300–400 functions in a binary that may contain hundreds of thousands (or more) across EXE/DLLs.
The same function can have very different effects depending on its execution window:
In most games, a large share of protection-related execution is intentionally placed during startup (often the majority, around 75–80%).
Figure 1. Game session timeline showing safer windows (startup/loading/transitions) vs gameplay-critical paths (in-game loop).
A performance-safe integration at launch does not automatically stay performance-safe forever.
Updates, patches and build or compiler pipeline changes can impact runtime behavior in ways that affect when functions execute or how they overlap.
What matters in the end is how functions execute in the compiled binary that players actually run. For this reason, integration should be treated as something to validate over time, with profiling and testing after major updates and build changes.
That perspective is most useful when it informs implementation decisions. The three principles below focus on practical choices that help keep protection-related execution away from gameplay-critical paths over time.
Anti-piracy integration should not be treated as a simple “add code here” step. A placement decision is also a runtime decision.
In practice, the Denuvo team starts by analyzing the shipped binary to identify candidate functions and evaluate their runtime behavior. The key questions are how frequently it executes, how long execution takes, which thread or execution context it runs in and whether it is tied to a gameplay-critical path.
This is the foundation of performance-sensitive integration: use runtime behavior to assess risk first, then choose placement accordingly.
Because a function may look safe on paper and still create risk at runtime, placement decisions should be validated in the shipped binary rather than inferred only from source-level expectations. Tooling and runtime analysis help teams review execution patterns, assess gameplay impact and make informed placement decisions.
We use a dedicated runtime analysis tool internally as part of this process, and we also share it with clients so publishers and developers can review the protected functions we selected, share any constraints or concerns, and make the final decision accordingly.
Figure 2. Example of anti-piracy function placement outside the gameplay loop.
Timing and execution context matter just as much as placement: the same function can have a very different player-visible impact depending on when it executes, which thread it runs on and what else is happening on that thread at the same time.
If protection-related execution happens during startup, loading screens or transitions, it is much less likely to affect active gameplay. These moments already include background work, which makes them better candidates for protection-related execution than gameplay-critical paths.
In practice, this can include startup sequences, logo and intro screens, new game loading and menu-to-game transitions. The goal is to concentrate protection-related execution on periods where players are least likely to feel it.
Performance-sensitive integration is not only about functions. It also depends on which thread executes those functions and what else is happening on that thread at the same time.
Code running on a gameplay-sensitive thread is more likely to create a visible impact than the same code running on a less sensitive thread. Because of this, thread choice should be treated as part of performance design and not as a secondary implementation detail.
This timing-focused approach is also broadly consistent with external reverse-engineering observations in specific titles.
In his Hogwarts Legacy write-up, Maurice Heumann describes interventions related to Denuvo by Irdeto as infrequent during regular gameplay and concentrated around major events such as scene switches and loading screens.
While this is one title-specific example, it provides a useful external illustration of the same execution-timing patterns teams should examine when evaluating placement and gameplay impact.
Denuvo by Irdeto is integrated at the binary level, which means protection can be applied without requiring source code modifications. That also makes re-validation important, because updates and build pipeline changes can shift runtime behavior in ways that affect when protected functions execute.
Even if an integration is performance-safe at launch, what was safe in one build may overlap differently in another. Re-checking runtime behavior after major changes is part of keeping gameplay performance stable over time.
Figure 3. Integration workflow: apply protection, review runtime behavior and re-check after updates.
The main takeaway is simple: player-visible impact depends on placement and execution. With careful placement, thread-aware decisions and re-validation over time, protection and gameplay performance can work together.
Does this perspective resonate with your approach to anti-piracy and performance? Contact Denuvo by Irdeto to discuss performance-aware integration.