szt
See what's taking up your disk.
Run szt (short for sizetree) in any folder to get a tree of where the space went: biggest first, every folder with the total of everything inside it, opened up only where the space is. On a Mac Studio it scans 667,000 files in 2.4 seconds, where du takes 17.
macOS 15+ · Native Swift binary · MIT licensed
szt on /Applications: 33 GB in 447,000 files, scanned in 1.2 seconds. Sizes and bars are colored from cool to hot by their share of the total, and by default the report fits in your terminal; --all prints every entry.
Installation
brew install urtti/szt/sztbrew update && brew upgrade sztHow it compares
szt against dua, dust, diskus, gdu, du and ncdu, each with its default settings, on a Mac Studio (M2 Ultra).1
- szt2.4 s
- dua2.6 s1.1× slower
- dust8.1 s3.4× slower
- diskus11.4 s4.7× slower
- gdu11.6 s4.8× slower
- du17.2 s7.2× slower
- ncdu17.5 s7.3× slower
Median of five runs per tool. Hover or focus a bar for CPU time and memory.
Everyday use
$ sztWhat's big in the current folder$ szt ~ -n 80The 80 biggest things in your home folder$ szt ~/Library -d 2No more than two levels deep$ szt . -m 1GOnly things of 1 GB or more$ szt ~/Downloads -aBy file length instead of space on disk$ sudo szt / -XThe whole startup disk, system volumes too
Why it's fast
A disk usage tool never reads your files. Sizes live in the file system's records, so the whole job is listing folders and asking how big each entry is. How a tool asks, and how many threads ask at once, turns out to be almost everything.
One call per folder, not one per file
Most tools list a folder's names with readdir and then make a separate call (stat, lstat or fstatat) for every file to learn its size. macOS has a better way: getattrlistbulk returns names, types and sizes for hundreds of entries at once. szt lists every folder that way, so a file never gets a system call of its own.
The per-file calls add up: in a profile of du on the projects folder, 60% of its CPU time goes to fstatat. The system calls each tool's binary imports show who does what:
| Tool | Lists a folder with | Then, for every file |
|---|---|---|
| szt, dua | getattrlistbulk | nothing |
| ncdu | getdirentries | fstatat |
| dust, diskus, gdu | readdir | lstat or fstatat |
| du | fts | fstatat |
dua is the other tool built on getattrlistbulk, which is why it's the close one in the benchmark.
More threads made it slower
With the per-file calls gone, what's left is opening each folder before listing it, and that has a ceiling. Here's szt on the projects folder with different thread counts:
| Threads | Time | Kernel CPU time |
|---|---|---|
| 1 | 12.80 s | 5.1 s |
| 2 | 6.52 s | 5.4 s |
| 4 | 3.27 s | 5.8 s |
| 6 | 2.66 s | 8.5 s |
| 8 | 2.50 s | 11.7 s |
| 10 | 2.70 s | 18.1 s |
| 12 | 3.58 s | 32.4 s |
| 16 | 7.63 s | 106.8 s |
| 24 | 10.59 s | 200.3 s |
A single thread spends much of its time waiting rather than working, so the first few threads help a lot. Up to eight the scan keeps getting faster. Past that it gets slower while the kernel works harder and harder: 24 threads burn 200 seconds of CPU time to finish in 10.6. A profile at 24 threads shows why: 93% of the time is spent inside open, the call that opens a folder so it can be listed. Opening a folder goes through vnode and name-cache bookkeeping that every process on the Mac shares (on this machine the vnode table was full, 263,168 entries out of 263,168, so an open often has to evict an old entry first). Past a handful of threads, they mostly wait for each other.
So szt stops at eight threads. dua's authors arrived at the same number: its thread count defaults to 8 on macOS and to the number of cores elsewhere. Most other tools start a thread per core or more, which on this 24-core Mac means 24 threads for dust and gdu and 72 for diskus. It shows in their CPU time: 122 to 211 seconds for the projects folder, against szt's 12.
Tuned, the per-file calls still cost about double
To tell the two effects apart, here are the other tools at their best thread count on the same Mac:
| Tool | Setting | Projects | Compared with szt |
|---|---|---|---|
| ncdu | -t 8 | 4.24 s | 1.8× |
| dust | -T 8 | 4.33 s | 1.8× |
| diskus | -j 8 | 4.55 s | 1.9× |
| gdu | -m 2 | 5.87 s | 2.4× |
With threads out of the picture they still take 1.8 to 2.4 times as long, and that's the price of asking about every file separately.
Efficiency cores don't help
Apple silicon mixes fast performance cores with slower efficiency cores. macOS runs background-priority threads on efficiency cores only, which makes it possible to try different mixes on one machine:
| Threads | Projects |
|---|---|
| 4 performance threads | 3.17 s |
| 4 performance + 4 efficiency threads | 3.09 s |
| 8 performance threads | 2.36 s |
| 8 efficiency threads | 6.55 s |
| 16 threads on the 8 efficiency cores | 7.15 s |
Four efficiency threads on top of four performance threads barely help (3.09 s against 3.17 s), and more threads than cores is a little slower. So szt starts one thread per performance core, as macOS reports in hw.perflevel0.physicalcpu, up to eight: four on a base M-series chip, and up to eight on the Pro, Max and Ultra.