Scanning my 141,696-file library took 6h 49m. Almost none of that was scanning.

I build Meshory, a desktop app that turns folders of 3D printing files into a library you can browse. My own collection is the benchmark: a NAS share with 141,696 files in 8,448 folders.

On 2 August the first scan of that library took 6 hours 49 minutes. On 4 August, same machine, same share, it took 7 minutes 18 seconds. I published both runs as raw JSON. The slow one broke down like this:

- Walking the folders: under a minute

- Saving the file list: a few seconds

- Reading archives: 3.5 minutes

- Rendering thumbnails: 355 minutes

- Extracting cover images: 27 minutes

- Hashing files for duplicate detection: 22 minutes

About 4.5 of those 409 minutes were scanning. Everything else had crept into the scan over time, one reasonable addition at a time. A thumbnail for every model feels like part of scanning a library. So does hashing.

The change was mostly structural. A scan now walks the folders, saves what it found and indexes the archives, and that's it. Thumbnails, covers and hashing happen afterwards in the background, and previews render whatever is on screen first. Peak memory during the scan went from 5,873 MB to 391 MB along the way.

That work still has to happen. On a library this size the previews keep rendering long after those 7 minutes, mostly because a lot of the models sit inside large zips on a NAS, and reading them over the network is the slow part. What the 7 minutes buys is being able to browse and search straight away. I'm spelling that out because a headline like 56x invites people to assume it covers everything.

The first time I ran the new version in the real app, the scan took nearly three times as long as in the benchmark. The background renderer had started competing with the scan for the same workers. Making it step aside while a scan runs fixed that, and a clean run in the packaged app now lands within a minute of the benchmark.

One number went the wrong way, too. Reading archives went from 3.5 to 6.3 minutes, and it's now most of what's left of the scan.

A later archive change made the whole scan about 11% faster, but reading archive directories, the part I wanted to speed up, got slower in aggregate. My own report concluded that the runs "do not support a directory read speedup claim", so I don't make one, and the page quotes that sentence word for word.

The raw runs and the machine spec are at meshory.com/engineering. It's one machine and one library, so treat it as evidence rather than a benchmark suite.

For anyone who has done a similar split: how did you decide what had to finish before the user could do anything? I only saw how much had crept in because I timed every phase separately.