Profiling findings from porting analyze: getattrlistbulk, cache writes on the scan path, du in-process

[ManfredFr]

Hi tw93 and everyone,

First: thank you for Mole. I have been using it for a while and it is the
first Mac cleanup tool I actually trust, mostly because of how carefully the
delete paths and the protection lists are written. The amount of macOS
edge-case knowledge in this repo is remarkable.

I want to be upfront about two things: I am not proposing that Mole adopt
Rust, and I am not asking anyone to review or maintain anything. I did a
port for my own use, learned some things while profiling it, and the findings
are language-independent — so they may be worth something to you even though
the port itself probably isn't.

What I did

I ported the analyze module (cmd/analyze/*.go) to Rust as an exercise, one
module at a time, treating your Go code as the specification. Every file in
the port names the Go file it came from.

The --json mode turned out to be the thing that made this feasible: I could
run analyze-go --json and my binary over the same tree and diff the output
structurally, so "is this correct?" had an actual answer instead of a vibe.
Whatever it was originally added for, it is an excellent testability
decision — thank you for it.

Current state: on /Applications (227 GB, 616k files) and
~/Library/Application Support (64 GB, 61k files), both binaries report a
0-byte difference in total size and identical file counts.

Findings that could apply to the Go code

All measurements are from an Apple Silicon MacBook on APFS, cold scans (fresh
HOME, so no cache reuse), binaries run sequentially and alternating. Big
caveat: these were measured in a Rust reimplementation, so the numbers would
land differently in Go. The directions should hold; the magnitudes may not.

1. getattrlistbulk(2) instead of readdir + per-file lstat — biggest single win

Replacing directory enumeration with getattrlistbulk (one syscall returns
names plus type, sizes, link count, dev/ino and atime for batches of entries)
was worth roughly 1.4x on its own:

	before	after
/Applications	3.70–3.79s	2.43–2.70s
50k-file synthetic tree	0.16–0.17s	0.11–0.12s

Two caveats I paid for by measuring:

• It only pays off where you need the names and types anyway. For a
  pure sizing walk (where you only want bytes), plain readdir + lstat
  measured about 2x faster than bulk — the per-entry kernel work for name
  resolution and attribute packing is not free. I ended up using bulk in the
  scanner and deliberately keeping readdir in the sizing walk.
• Reusing one attribute buffer per thread mattered; allocating and zeroing a
  fresh 256 KB buffer per directory ate a visible chunk of the win on trees
  with many small directories.
• The attribute mapping is a trap. I first asked for
  ATTR_FILE_TOTALSIZE, which sums all forks, and it silently inflated
  every resource-forked file (audio components, plugins) — a 52 MB gap
  against analyze-go on a /Library scan. stat(2) is asymmetric and the
  mapping has to match it exactly:
  st_size = data fork = ATTR_FILE_DATALENGTH, but
  st_blocks = all forks allocated = ATTR_FILE_ALLOCSIZE.
  Ordinary test fixtures have no resource forks, so this hides. If you try
  it, put a file with a resource fork in the fixture.

In Go this needs a raw SYS_GETATTRLISTBULK syscall rather than a ready-made
wrapper, plus record parsing, so it is a real chunk of work — but it is the
single highest-leverage change I found, and it is entirely independent of
implementation language. Keeping readdir as a runtime fallback (and a test
asserting both enumerators return identical attributes) made it safe to
adopt.

2. Cache writes sit on the scan's critical path

saveCacheToDiskWithOptions is called inline from scanSubdirWithCache, so
scan workers serialize, write and rename cache files while the scan is still
running. One cold /Applications scan writes 4,430 cache files.

Measured in my port: 2.45s with inline cache writes vs 2.0s with cache
I/O disabled entirely — so roughly 18–20% of a cold scan is cache
persistence. Moving it to a background writer drained after the scan brought
it to 2.19–2.26s.

The counterintuitive part, and the reason I mention it: more writer threads
did not help. Four writers performed the same as writing inline (~2.45s); a
single background writer was the fast configuration. The cost is
filesystem-layer contention with the scan's own metadata reads, not worker CPU
time. If you try this in Go, a buffered channel plus one writer goroutine
(drained before exit) looks like the shape that wins.

3. Cache admission may be looser than the design intent

The budget comment in constants.go reasons that the thresholds keep "the
~1.5% of entries that carry the reuse value". With
subdirCacheMinFiles = 100 / subdirCacheMinSize = 10 << 20, a single
/Applications pass still admitted 4,430 entries on my machine. That may
be entirely intended, but given the history described in that comment (1.88M
files / 7.82 GB for one user) it might be worth re-measuring the distribution
against the current thresholds.

4. The du subprocess for folded directories can be replaced in-process

I replaced the du -skPx subprocess with an in-process parallel walk
reproducing its semantics exactly — physical size (st_blocks * 512) for
every entry including directories, hardlinks counted once per tree by
(dev, ino), symlinks counted as the link, no device crossing, -I basename
ignores. Unit tests assert it matches real du output byte-for-byte on
fixture trees.

Besides removing the fork/exec, this dissolves the duSem / duQueueSem
contention and the "du timed out on a huge tree, now fall back to a slow
re-walk" failure mode.

5. Spotlight runs after the walk instead of alongside it

findLargeFilesWithSpotlight is called once the walk has finished, so its
latency is fully additive. Starting the mdfind query when the scan starts
and joining at the end would hide it. Honest disclosure: on my machine those
queries measured only ~0.05–0.06s, so this is small — but it is close to free.

6. ~/Library/CloudStorage may deserve the Mobile Documents treatment

A full home-directory scan took ~67s here, and the overwhelming majority was
macOS File Provider enumeration of Dropbox placeholders — neither
implementation was meaningfully faster, because it is all waiting on the OS.

You already special-case Mobile Documents in overviewDuIgnoreNames for
exactly this reason on the iCloud side. ~/Library/CloudStorage (Dropbox,
OneDrive, Google Drive via File Provider) has the same characteristic. Clearly
a product decision rather than a bug, but the parallel seemed worth pointing
out.

On the port itself

I am publishing it as brrw, with its own name and icon, no Mole branding,
and a clear "unofficial, not affiliated or endorsed" notice, per your
TRADEMARK.md. It stays GPL-3.0, credits Mole prominently as the origin, and is
explicit that it covers only the analyze module — Mole remains the complete
and mature tool.

If any of the findings above are interesting, I am happy to open individual
issues with the detail, or to attempt them as Go PRs against Mole — I would
rather contribute upstream than fork quietly. Equally, if you would prefer I
just leave you to it, that is a completely fine answer and I will not be
offended.

Thanks again for the tool and for making it open source.

[tw93]

@ManfredFr This is the most useful report anyone has sent this project, and I am sorry it sat for two weeks. I have read all six findings against the current code and every one of them lands on something real, so let me answer them individually rather than thank you generically.

The du subprocess (4). This is the one I want most, and not mainly for the fork and exec. duSem and duQueueSem exist because I could not bound that subprocess any other way, and the "du timed out, now re-walk slowly" path is a failure mode I have never been happy with. An in-process walk reproducing -skPx semantics exactly, with the (dev, ino) hardlink handling and tests asserting byte-for-byte agreement with real du, removes all three at once. If you open one PR, make it this one.

Cache writes on the scan path (2). Correct, saveCacheToDiskWithOptions is called inline. The counterintuitive half is the valuable half: I would have reached for a worker pool and measured nothing. A buffered channel with a single writer goroutine, drained before exit, is a shape I would merge.

getattrlistbulk (1). Correct that Go needs a raw syscall plus record parsing, which makes it the largest piece of work here. The ATTR_FILE_DATALENGTH versus ATTR_FILE_ALLOCSIZE asymmetry is the kind of trap that would have cost me a week, and a fixture containing a real resource fork is going into the tests regardless of whether the syscall change ever lands. If it does land I want the readdir fallback and the both-enumerators-agree test you describe, and I want it after the two above rather than before.

Cache admission (3). Worth re-measuring, and 4,430 admitted entries in one /Applications pass is reason enough on its own. This is a measurement question rather than a patch, so the distribution posted as a comment would be more useful to me than a PR that moves the constants.

Spotlight (5). You measured it at 0.05s and said so rather than presenting it as a win. That is a large part of why I trust the rest of the report. Correct, but not worth the concurrency. Leave it.

~/Library/CloudStorage (6). You read the intent correctly, and overviewDuIgnoreNames having exactly one entry with that comment is exactly why. My hesitation is that people keep genuinely local data under CloudStorage far more often than under Mobile Documents, so skipping it in the overview would hide real usage rather than placeholders. Your 67 seconds is a good argument that the current behaviour costs more than that tradeoff assumes. Open it as its own discussion and let it be argued on its own terms.

On brrw: thank you for reading TRADEMARK.md, and for the separate name, separate icon and explicit non-affiliation notice. That is exactly the right way to do it and I have no objection. Publish it.

Please do open the PRs. Start with du.

[tw93]

@ManfredFr Finding 3 measured, since that one was mine to answer rather than yours to patch.

Cold scan of /Applications on an Apple Silicon Mac, fresh HOME, 255,015 entries / 18 GB, 2s: 764 admitted entries, 3.9 MB of cache.

	median	p25	p75	p90	max
files per entry	131	15	375	727	39,238
size per entry	16.8 MB	2.3 MB	63.3 MB	344.7 MB	1.8 GB

38% of admitted entries (290) hold fewer than 100 files; they cleared the size threshold alone. Re-applying stricter rules to the same population: files >= 100 only keeps 62%, raising the size floor to 100 MB keeps 67%, requiring both keeps 28%.

I am leaving the constants alone. The thresholds already did the job they were written for, from the 1.88M files / 7.82 GB in the constants.go comment down to 3.9 MB here, and the 290 low-count entries cost about 1.5 MB between them. Tightening would mostly evict directories that are few files but large, which are the ones whose rescan is most likely to reach du.

One caveat on my own number: you measured 4,430 entries on 616k files, I measured 764 on 255k. That is 2.4x the entries producing 5.8x the cache files, so tree shape drives this more than tree size and neither of our single samples generalises.

Status of the rest, so nothing is left implied: du in-process (4) and the single background cache writer (2) are the two I want, in that order, and they are yours whenever you get to them. getattrlistbulk (1) after those, with the readdir fallback and the both-enumerators-agree test. Spotlight (5) stays as it is. CloudStorage (6) belongs in its own discussion.

Closing this one, since every finding now has an answer. Open the PRs as PRs; they do not need this thread.