Skopos Disk map Footprint Benchmarks Pricing

Benchmarks

The method, before the numbers.

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.

Why the total matters more than the time

A worked example, from the 0.7.4 baseline run — the live figures are in the results table below. On this machine, a naive scan reported 990.7 GB on a 500 GB disk. Three separate mistakes produce that, and every one of them is easy to make:

  • Folders reachable two ways. Your home folder can be walked by two different routes on a modern system, and the two routes do not obviously look like the same place. A scanner that does not notice counts half the disk twice.
  • Neighbouring volumes. Several hidden system volumes share the same physical disk — swap, recovery data, mounted disk images whose contents are already counted where the file lives. Sweeping them into one total inflates it.
  • Files with more than one name. 292,726 names here pointed at a file already counted under a different name, between them accounting for 17.0 GB that only exists once.

Corrected, the scan reported 437.1 GB — and it finished in half the time, because half of what it had been walking was never really there.

The cross-check

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:

~/git skopos 76.0 GB du -sk 76.1 GB (naive walk: 87.6 GB)

And the whole-volume arithmetic is published rather than rounded away:

437 GB mapped, every byte once 472 GB reported in use by the volumes scanned 34.5 GB the difference — 456 folders it was refused access to, plus space the system can reclaim on demand, which has no files to walk 15.3 GB free

How each tool is timed

Same machine, same volume

MacBookPro16,1 (six-core Intel, macOS 15.7.9) with a 500 GB drive, scanning /. Nothing else running; the machine is left to settle first.

Warm caches, three runs

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.

Memory by sampling

ps -o rss= every 200 ms for the life of the scan, peak reported. The sampler trace is published with the result.

Completion is operator-marked

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.

Results

Skopos and Disk Inventory X are measured, in one session on the same machine, median of three runs each. DaisyDisk and GrandPerspective are still being set up — as are iStat Menus and Stats for the idle table below — and a row with guesses in it would be worse than an empty one, so those stay blank until they run.

Disk scanners — full scan of /, warm cache, median of three. Elapsed time and peak RSS sampled every 200 ms; memory range in brackets. One session, same machine for every tool, macOS 15.7.9.
ToolTimePeak memoryTotal reportedCounts each file once
Skopos 0.7.432.3 s172 MB (144–181)427.5 GBYes
DaisyDisknot yet measured———
GrandPerspectivenot yet measured———
Disk Inventory X466 s7,238 MB (6,468–7,264)442.4 GBYes

Skopos and Disk Inventory X disagree on the total by about 15 GB — Skopos maps a little under the volume's used figure, Disk Inventory X a little over. That is a margin question, not the double-count: neither reports the ~795 GB a plain walk of / still produces here. Which counting rule accounts for the gap is being pinned down separately.

Menu-bar monitors — default settings, whole-process CPU and RSS sampled every 200 ms for 90 seconds. Median of n runs, full range in brackets. Machine had 957 live processes throughout. Skopos measured after a full-volume scan, its worst case; n=4.
ToolIdle CPUIdle memoryNetwork
Skopos 0.7.40.79 % (0.54–0.99)79 MB (73–100)None
iStat Menusnot yet measured——
Statsnot yet measured——

Two caveats we would rather state than bury

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, so a reading taken right after a scan sits higher than one taken later. Across three back-to-back runs the peak drifted from 144 MB to 181 MB as reclaimed memory lagged the next scan; the range in the table spans that drift 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 a six-core (twelve-thread) 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.