Is my computer actually getting slower?

Measure the thing you actually care about

Benchmark scores are a poor proxy for the complaint. Nobody minds that their synthetic multi-core figure dropped four per cent. They mind that the project takes ninety seconds to open when it used to take twenty.

So time that. Whatever the actual annoyance is — a build, an export, an application launch, a script — run it repeatedly and record how long it takes. It is the most relevant possible measurement and it needs no special tooling.

The general benchmark has one job: telling you which part of the machine moved, once you already know something did.

How to time something so the number means anything

Four rules, all of which get broken constantly:

Warm up first. The first run pays for caches being cold, files not being in memory, and code not yet being compiled. Discard it.

Run it many times. Thirty is a good number for anything short. A single measurement of a noisy system is a random number.

Use the median, not the mean. One run interrupted by a background update drags an average badly and does not move a median at all.

Report the spread. A median of 20 seconds with runs from 19 to 21 is a stable machine. A median of 20 with runs from 12 to 51 is a machine with a problem, and the problem is the variance itself.

Then save the result. A number from today is only useful against a number from before.

What usually turns out to be the cause

In rough order of how often it is actually the answer:

• A full disk. Both Windows and macOS get dramatically worse near capacity, and an SSD with no free blocks to write into is slow at everything. This is the first thing to check and often the whole answer — see what is filling my drive.
• Thermal throttling. Fast for thirty seconds, then half speed. Dust in the fans, a blocked vent, dried-out thermal paste, or a laptop on a duvet. The signature is that a sustained load starts fine and degrades; a short benchmark misses it entirely.
• Something running that you did not start. A sync client reindexing, an antivirus scan, a search indexer, an update service. Check what is using the CPU while it is slow, not afterwards.
• Too many startup items accumulated over years.
• A failing drive, retrying reads. See is my drive failing.
• Software genuinely got heavier. Browsers and editors are not the size they were in 2019. This one is real and there is nothing to fix.

The sustained-load test

The single most informative test on an older laptop is not a short benchmark. It is loading every core for five minutes and watching what the throughput does.

A healthy machine holds its speed. A thermally limited one starts at full pace and settles somewhere lower, and where it settles is the number that describes what you actually get during a long job. Short benchmarks reward exactly the machines that fail this test.

The programs for this

• SystemPulse times a command properly: bench runs it as many times as you say, with warm-up runs discarded, and saves the result as a baseline. compare re-runs it later against that baseline and tells you whether it has moved by more than a threshold you set — so “it feels slower” gets a yes or a no.
• PerformanceDeck gives the composite figure and the breakdown behind it, so when the score drops you can see which component moved.
• ThermalFlow keeps the history. It appends a benchmark round to a file on a schedule and flags the day the machine got slower, which is the question you actually wanted answered.
• CorePilot answers the narrower one: how much faster is this machine with every core than with one? Poor scaling is its own diagnosis.
• SensorDeck is the sustained-load one: load the machine for five minutes and see whether it holds its speed.

Free while we are in preview, one file each, Windows and Mac.

What none of these read

Temperature. Fan speed. Voltages. Reading those requires privileged access to platform-specific hardware interfaces, and none of these programs do it — which is worth saying plainly, because a lot of tools in this category imply they do.

What they measure is throughput over time, which detects thermal throttling by its effect rather than by its cause. If you want the actual temperature, use your motherboard vendor’s utility, or powermetrics on macOS.