Short answer
Measured on 23 October 2026 on one PC, in a fake game with the engines on, w0a's own process used on average:
- 0.15% of one logical processor (the PC has 16)
- 7.2 Mcycle/s, that is 7.2 million processor cycles per second
- 29.6 context switches per second
Its working set, the memory it held in RAM, averaged between 102 and 120 MB in the four states measured (119.6 MB in this one).
None of these is zero. Runs on a busier PC follow further down.
Not measured in a real game. The game was a fake one: a program that shows a black full-screen window and draws nothing.
What the numbers mean
- Percent of one logical processor. 0.15% is 1.5 ms of processor time in every second, on one of the 16 logical processors. Windows counts this time in steps of about 15.6 ms, so most one-second samples read 0.00% (the median) and a sample that catches one step reads 1.56% (the 95th percentile). That is why the next figure is the main one.
- Cycles (Mcycle/s). Millions of processor cycles per second used by w0a's threads, read from Windows' cycle counter for each thread, which does not round to steps. The median was 5.8 Mcycle/s. For scale: 1 GHz is 1,000 million cycles per second.
- Context switches. How many times per second one of w0a's threads was put on a processor to run, added up over all its threads. Each one is a thread woken to do some work.
- Working set. The part of w0a's memory held in RAM. In the game with the engines on it averaged 119.6 MB and peaked at 122.7 MB.
The four states
Each state lasted five minutes. "Engines off" means every part of the Game Mode switch except the power plan was off. The power plan was not touched during the run: w0amax stayed active the whole time.
| State | Cycles, average (median) | Percent of one logical processor | Context switches per second | Working set |
|---|---|---|---|---|
| Idle, engines off | 4.5 (2.4) Mcycle/s | 0.09% | 10.9 | 103.2 MB |
| In game, engines off | 1.7 (1.5) Mcycle/s | 0.08% | 10.7 | 108.2 MB |
| Idle, engines on | 5.3 (2.9) Mcycle/s | 0.10% | 13.9 | 102.0 MB |
| In game, engines on | 7.2 (5.8) Mcycle/s | 0.15% | 29.6 | 119.6 MB |
The rows were measured one after another while other programs on the PC kept running and starting, so a difference between two rows cannot be put down to the engines alone.
With the engines off, idle reads higher than in game. Each w0a was measured idle first, soon after it started, and in that stretch the .NET runtime was still compiling w0a's code in the background: 2.30 Mcycle/s, 51.4% of the idle total (51.6% with the engines on). In the game with the engines off it was down to 0.41 Mcycle/s. That drop, 1.9 Mcycle/s, is about two thirds of the 2.8 Mcycle/s difference.
How it was measured
- PC: AMD Ryzen 7 9800X3D (8 cores, 16 logical processors), 31.6 GB of RAM, NVIDIA GeForce RTX 5070 Ti, Windows 11 Pro build 26200.
- w0a: version 2.1, the build published on 23 October 2026. It ran in the notification area with its window closed. Only the engine switches changed between states, and they were set back afterwards.
- Sampler: once a second, a separate measuring program read w0a's process through Windows'
NtQuerySystemInformation: the processor time, cycles and context switches of each thread, and the working set. Each state gave 300 samples. - Fake game: a 1920×1080 full-screen window that presents 240 black frames per second through DXGI on its own timer. It ran in the foreground, and
engine.logshows w0a took it for a game and, with the engines on, raised its priority to AboveNormal. Another program's window stayed on top of it. - Order: first the fake game ran for 2 minutes without w0a, as a reference. Then w0a was started with the engines off, given 90 seconds to settle, measured idle, then measured with the fake game running after the game had 40 seconds to settle. The same followed with a freshly started w0a with the engines on.
- Load on the PC: the run started on a quiet PC, at 3% total processor use. During the in-game state with the engines on, 165 processes were running and w0a counted 38 to 523 new ones starting per minute.
What the fake game showed
It presented 240 frames per second in all three in-game runs, with and without w0a. Its own processor use was 203.4 Mcycle/s without w0a, 205.5 with the engines off and 207.5 with the engines on. This run does not show where that difference comes from, so it is not counted as w0a's. The fake game draws nothing, so it says nothing about frame times in a real game.
With the engines on, w0a counts the game's frames through Event Tracing for Windows (ETW), filtered to the game alone. The game's own process writes those events as it presents each frame, so that share of the cost lands in the game's numbers, not in w0a's. How large that share is was not measured.
On a busier PC
Two later runs on the same PC, on 24 October 2026, put load around the fake game. They used newer builds of w0a, published that day, with the engines on.
- 71 minutes in four stretches: background threads keeping every logical processor 50% busy; then 25% plus 150 MB/s of disk reads; then 50% plus 100 MB/s of disk reads plus a short-lived program every 5 seconds; then no added load. The fake game also started a short helper program every 90 seconds, and w0a had been running since before the start. Per stretch, w0a averaged 0.12% to 0.17% of one logical processor and 5.1 to 7.2 Mcycle/s.
- Four new programs a second, in two runs of two and a half minutes: w0a counted 637 and 648 starts per minute. It averaged 0.30% and 0.25% of one logical processor, 14.8 and 14.6 Mcycle/s, 66.9 and 68.0 context switches per second, and 117.1 and 116.7 MB of working set. Each w0a had been started 90 seconds before its measurement, and the .NET runtime's compiling still took about 5.3 Mcycle/s of it.
Every program that starts reaches w0a as an event, and w0a looks at each one; with reserved cores on, it also decides whether to move the program off the game's cores. The more programs start, the more of that work there is. These runs used newer builds and a different load, so they are not a before-and-after comparison with the table above.
What was not measured
- A real game. The game here was a fake one that draws nothing. w0a's cost next to a real game was not measured.
- Frame times. Whether the engines change your game's frame times was not measured here. To measure it on your own PC, run an A/B series in the benchmark with A: engines off and B: engines on, as described in Reading the benchmark.
- Other processors. Only one processor was measured, the 8-core AMD Ryzen 7 9800X3D. On a processor with fewer or slower cores the same work is a different share; how different was not measured.
- w0a with its window open. The window was closed throughout. With it open, the cost was not measured.
- Graphics card, disk and network. Only w0a's processor time and memory were measured.
- Work outside w0a's process. Part of the work of delivering events to w0a, such as a program starting or a frame being presented, is done by Windows or by the game, outside w0a's process. That part was not measured.
Turning the engines on and off
The engines are all off on a new installation. They are the parts of the Game Mode switch on the Process Manager page.
To see what the engines did during your own game, open engine.log: one line per action. perf.log beside it has lines on what some of them cost during the game. Both are explained in Where the log file is.
Related
Of the dozen or so stages between a click and a changed pixel, software owns three; the firmware, the display and the game own the rest: How to reduce input lag: what software can and cannot shorten
Did this page help?
What was missing, or what did not work? We read every one of these.
If this page did not solve it, write to us — say which article you read, and we will fix the article.