Methodology
Most PC bottleneck calculators give you a percentage and leave you wondering where it came from. We take a different approach.
Our PC Bottleneck Calculator shows you how the result is calculated, what factors influence it, and which assumptions can affect the accuracy of the estimate. Instead of treating the bottleneck percentage as a magic number, we explain the reasoning behind it in plain language.
Below, you'll find the full bottleneck calculation formula, along with the assumptions and limitations you should know before using the result.
This makes it easier to understand whether your CPU and GPU are well matched, where a potential performance bottleneck may occur, and why the calculator's estimate might not perfectly match real-world gaming performance.
The model in one paragraph
Each processor has a frame rate limit: the maximum average frame rate it can achieve in a modern AAA game with an infinitely fast graphics card. Each graphics card has three frame rate limits, one for each resolution, which is the maximum it can do if the processor were infinitely fast. Both limits are then adjusted to the workload you selected and the memory each part is required to work in. Your result is the minimum of the two, minus a tax for the drive class. The difference between the two limits is unused capability that you paid for.
Resolution decides which of a card's three frame rate limits applies. Memory, storage and usage type do not set a limit of their own, they move the two that already exist, which is why each is reported as its own percentage rather than a fourth bar.
The formula
cpuCeiling = cpu.ceiling × usage.cpuMul × fit(ram, usage.ramWant)
gpuBase = mix(gpu[resolution], gpu[1080p], usage.resWeight)
gpuCeiling = gpuBase × usage.gpuMul × fit(gpu.vram, usage.vramWant)
matched = min(cpuCeiling, gpuCeiling)
faster = max(cpuCeiling, gpuCeiling)
unused = (faster - matched) / faster × 100
limiter = whichever ceiling is lower
driveTax = (1 - storage.index) × usage.storageWeight
delivered = matched × (1 - driveTax)
fit(have, want) = have >= want
? 1
: max(0.5, 1 - 0.18 × log2(want / have))Results are then placed in one of four bands:
| Unused capability | Verdict | Should you act? |
|---|---|---|
| under 5% | Well matched | No |
| 5–15% | Limited, barely | Free fixes only |
| 15–30% | Limited | Worth addressing |
| over 30% | Holding the build back | Yes, if you use the frames |
The other three inputs
Resolution decides which of a card's three frame rate limits applies. The remaining three inputs do not set a limit of their own; they move the two that exist, which is why each is reported as its own percentage rather than as a fourth bar.
| Input | What it changes |
|---|---|
| Usage type | Reweights both frame rate limits. Streaming moves capture and encoding onto the processor, leaving about 80% of its gaming capability for the game itself. AI work runs almost entirely on the graphics card, so the processor stops being the constraint. Everyday desktop use leaves the graphics card close to idle. Usage type also sets how much resolution matters and how much memory the workload needs. |
| Memory | Applied to the processor side, because that is where paging and stalls land. Running at half the memory the workload wants costs about 18%; a quarter of it costs about 36%. Above the comfortable figure extra capacity does nothing, more memory is not faster memory. |
| Storage type | Applied to the delivered figure rather than to either limit, and scaled by how much the workload waits on a disk. Gaming is barely affected. Video editing and general responsiveness are affected a great deal. |
The verdict names whichever of these costs the most. The four losses are not on the same scale and do not add up, so the useful question is not “how much am I losing in total” but “what would I fix first”.
Why the frame rate is not the headline
The bottleneck percentage is the headline and the estimated frame rate sits underneath it. The percentage is the number that still means something when the workload is not a game and frames per second is not the unit, and it answers the question people arrive with: am I wasting one of these parts? Read the two together. Dropping from 80 to 60 FPS on a 144 Hz monitor matters; dropping from 200 to 150 on a 60 Hz monitor does not.
The numbers are from where?
The frame rate limits are based on the average frame rates of a sample of recent AAA games at high preset, with no ray tracing and no upscaling, and normalised to a common test scene. We do not publish or distribute any third party benchmark database, nor do we scrape commercial benchmark sites.
Every figure on this site is modelled, not measured. The frame rate limits come from the model described above, calibrated against published benchmark averages for a set of reference parts, then extended across the database from architecture, clock speed, core count and memory configuration. No figure here is a benchmark result, and none is copied from a commercial benchmark database.
What the model deliberately ignores
- Memory speed. Capacity is modelled. Speed and timings are not, and they are frequently worth another 5 to 15% on the processor side. Covered separately in the article on memory.
- Individual games and individual applications. A flight simulator and a competitive shooter load your hardware in almost opposite ways, and so do Premiere and Blender. Usage type is a coarse category, not a benchmark of your software.
- Ray tracing and upscaling. Both move the balance around substantially and in opposite directions.
- 1% lows and frame pacing. Averages hide stutter, which is often what people actually notice.
- Cooling, power limits and platform. The same processor performs differently in a laptop, in a small case, or on a board with weak power delivery.
- Drive capacity, fullness and driver overhead. Drive class is modelled as a flat tax. Which drive the game is actually installed on, how full it is, and how good the storage stack is are not.
- Anything for non-gaming workloads beyond the reweighting above. For video editing, 3D and AI the output is a relative capability score built from gaming frame rate limits, not a measured render time. Use it to compare configurations against each other, not to predict how long an export will take.
How accurate is this?
Use it as a shortlisting tool, with an error margin of about ±15% compared to a real benchmark run, larger in games with unusual engines. It's great at saying "will this card be wasted on my processor" and terrible at saying "exactly how many frames will I get in this particular game.
If you already have a machine, a five minute overlay test beats this model outright. Here is how to run it.
Corrections
If a figure looks wrong and you have benchmark data to back that up, send it to [email protected]. Corrections get made and credited.