Benchmarks
A speed claim about a disk scanner is meaningless without the counting rule attached. Two tools can scan the same volume, disagree by 500 GB, and both finish quickly. This page says exactly what was measured and how, so the result can be argued with.
On this machine, a naive scan reports 990.7 GB on a 500 GB disk. Three separate mistakes produce that, and every one of them is easy to make:
Corrected, the scan reports 437.1 GB — and it finishes in half the time, because half of what it had been walking was never really there.
A total nobody can check is worth nothing, so it is held against
du, the standard tool for the job, which has been getting this
right since 1971:
And the whole-volume arithmetic is published rather than rounded away:
MacBookPro16,1 with a 500 GB drive, scanning /. Nothing else
running; the machine is left to settle first.
A warm re-scan is no faster than a cold one here — 30.0 s cold against 34.2 s warm — so the cost is per-entry kernel work, not the device. Warm is therefore both fair and repeatable. Median of three.
ps -o rss= every 200 ms for the life of the scan, peak
reported. The sampler trace is published with the result.
No GUI app announces that it has finished. A person watches and marks the moment the finished map is on screen. Stated openly because it is the one subjective step.
Skopos's own figures are measured. The comparison rows are not filled in yet — DaisyDisk and iStat Menus are being set up, and a table with guesses in it would be worse than an empty one. This page updates when they run.
| Tool | Time | Peak memory | Total reported | Counts each file once |
|---|---|---|---|---|
| Skopos 0.7.4 | 59.9 s | 108 MB | 437.1 GB | Yes |
| DaisyDisk | not yet measured | — | — | — |
| GrandPerspective | not yet measured | — | — | — |
| Disk Inventory X | not yet measured | — | — | — |
| Tool | Idle CPU | Idle memory | Network |
|---|---|---|---|
| Skopos 0.7.4 | 0.79 % (0.54–0.99) | 79 MB (73–100) | None |
| iStat Menus | not yet measured | — | — |
| Stats | not yet measured | — | — |
Idle CPU figures move with machine load. Four runs of the same build an hour apart measured 0.54%, 0.71%, 0.87% and 0.99% — nearly a factor of two, with nothing changed but what else the machine was doing. That is why the table shows a median and a range instead of one confident number. Treat a single reading as an estimate; the numbers here are medians taken on a settled machine, and the app's own test suite enforces a budget of 1.6× the target rather than an exact figure, because a gate that tight fails for reasons that have nothing to do with the code.
Memory after a scan comes back slowly, not instantly. Closing the disk map stops the scan and frees what it was holding, but macOS takes that memory back gradually rather than all at once: measured across one session, 124 MB with the map open, 103 MB a minute after closing it, and 82 MB twenty minutes later. The range above spans that whole decline rather than quoting the flattering end of it.
This is not the same figure as the engine's self-cost. Skopos's test suite reports how long one sample of the engine takes as a fraction of the sampling interval — about 0.4% with the panel closed. That is a smaller number measuring a smaller thing. The table above is whole-process CPU, including the menu-bar item and everything AppKit does, because that is the only figure that can be measured the same way for every tool here.
These are one machine's numbers. A MacBookPro16,1 is an eight-core Intel laptop. Thread scaling, and therefore scan time, will differ on Apple Silicon. When those runs exist they will be published beside these rather than replacing them.