Scan time is one of the first things people judge a storage tool by, but the honest answer to "why does this take 90 seconds" involves more than the tool's own code — it's shaped heavily by the filesystem underneath it and by choices about what to measure and how thoroughly.

What a scan actually has to do

At minimum, a storage scan has to enumerate every directory entry from the starting point downward, and for each file, read its metadata — size, and for a thorough tool, whether it has multiple hard links, whether it's sparse, whether it's a symlink. This is a large number of small filesystem operations: a project folder with a deep node_modules tree alone can contain hundreds of thousands of individual files, each one a discrete piece of metadata to read.

The cost is dominated less by the total bytes on disk and more by the number of individual filesystem entries, which is why two folders of identical total size can take wildly different times to scan — a folder holding one 50GB video file scans almost instantly, while a folder holding 500,000 small cache files at a fraction of that total size can take much longer, because the bottleneck is metadata lookups, not data throughput.

Why APFS enumeration cost varies

APFS, the filesystem macOS has used since 2017, is generally efficient at directory enumeration compared to older filesystems, but a few things still affect real-world scan speed on it:

  • Storage medium. An internal SSD handles the high volume of small random reads a directory walk generates far better than a spinning hard drive or many external drives connected over a slower interface, where each metadata lookup carries more latency.
  • Directory depth and fan-out. A tree that's both deep and wide (many folders, each with many subfolders) generates more individual system calls than the same total file count arranged in a flatter structure.
  • Concurrent filesystem activity. A scan running while Spotlight is actively indexing, or while Time Machine is mid-backup, competes for the same underlying I/O and metadata caches, and will run slower than the same scan on an otherwise idle disk.
  • Cold versus warm cache. The very first scan of a folder in a while does more physical I/O; a second scan shortly after can benefit from data macOS has already cached in memory, and often completes noticeably faster purely for that reason, independent of anything the tool itself does differently.

Full scans versus incremental rescans

A full scan walks the entire target from scratch every time. An incremental rescan instead tries to update only what's changed since a previous scan — checking modification timestamps on directories to decide whether their contents need re-reading at all, and skipping the ones that haven't changed.

Incremental rescanning can meaningfully speed up the common case of "I cleaned some things up, let me check the new total" without requiring a full re-walk of an entire home folder. Its accuracy depends on correctly detecting every kind of change, though — a implementation that misses an edge case (a file replaced without updating its parent directory's modification time in the way the tool expects, for instance) risks reporting a stale number. A tool offering incremental rescans should be scanning fully often enough, or on explicit request, to correct for any drift this could introduce.

What makes a scan feel fast, independent of raw speed

Perceived speed and actual speed aren't the same thing, and the gap matters for user experience even when the underlying work is identical.

  • Progressive results beat a blank screen with a spinner. A tool that starts showing you the top-level folders as soon as they're counted, then fills in detail as the scan continues, feels faster than one that shows nothing until the entire walk completes — even if the total wall-clock time is the same.
  • An accurate progress indicator (based on directories or files counted so far against a running estimate) feels better than an indeterminate spinner, because it gives you a sense of whether to wait ten more seconds or go do something else.
  • Responsiveness during the scan — being able to click into a folder that's already been counted while the rest of the scan continues in the background — removes the feeling of being blocked, even if total scan time hasn't changed at all.

A tool that is technically fast but shows nothing until the very end can feel slower than a tool that's technically a bit slower but shows useful information the whole way through.

Why concurrency helps, but only up to a point

Modern storage tools generally scan multiple directories concurrently rather than walking the tree in a single sequential pass, since a modern SSD can service several concurrent read requests faster than one at a time. This genuinely helps, but there's a ceiling: too much concurrency competing for the same underlying disk queue can start working against itself, adding scheduling overhead without a corresponding gain in throughput, and on a spinning hard drive specifically, excessive concurrent access can actively hurt performance by forcing the drive head to jump between unrelated regions rather than reading sequentially.

A well-tuned scan engine bounds its own concurrency to a sensible level for the underlying storage rather than firing off unlimited simultaneous work per file or folder — enough to benefit from an SSD's parallel read capability without overwhelming the system or crowding out other work you're doing at the same time.

The role of previously cached metadata

Beyond a simple cold-versus-warm cache distinction, macOS itself maintains various levels of filesystem metadata caching that a scan can benefit from indirectly, even without a tool doing anything special. If you've recently opened a folder in Finder, used Spotlight to search within it, or run a previous scan with any tool, some of the metadata a new scan needs may already be resident in memory rather than requiring a fresh disk read. This is part of why re-running the same scan shortly after the first one often feels noticeably snappier — it's not necessarily the tool getting smarter, but the underlying system already holding relevant data from the first pass.

What to reasonably expect

There's no universal number that applies across all Macs, drives, and folder structures — a scan time that's normal for a home folder with half a million files on an older SSD is not directly comparable to the same tool running against a much smaller, flatter folder on current hardware. If a scan seems unusually slow relative to your own past experience with the same tool on the same Mac, checking for concurrent disk activity (Spotlight indexing, an active Time Machine backup) is a reasonable first troubleshooting step before assuming the tool itself has slowed down.

Where VolumeLens fits

VolumeLens is built with bounded, structured concurrency for its scan engine rather than spawning unbounded work per file, specifically so scans stay responsive and don't overwhelm the system while running. Results appear progressively as folders are counted, so you're not staring at a blank screen while a large home folder gets walked. You can see how it performs on your own disk by downloading VolumeLens — there's no faster way to know than trying it against the folders you actually care about.