Metadata is cheap; content hashing is not
Listing metadata for thousands of selected files is usually much cheaper than reading every file’s bytes. The workbench therefore renders an inventory first and narrows duplicate work with size groups. Hashing begins only after you request verification.
Where the browser spends resources
- Selection: creating many
Fileobjects and relative paths. - Rendering: sorting, filtering, and displaying a table. The interface paginates the inventory instead of inserting every row into the document.
- Hashing: reading complete candidate files into memory and calculating SHA-256.
- Export: serializing all records into CSV or JSON and creating a download blob.
Why the table is paginated
A browser can hold thousands of records in memory without creating thousands of visible table rows. Pagination limits the amount of document work during each render. Search and sorting still operate on the full in-memory array, but only the current page is inserted into the DOM.
Why hashing is sequential
Parallel hashing can appear faster on a small set, but each arrayBuffer() call may allocate the size of the file. Ten 200 MB candidates started together can require roughly two gigabytes of file buffers before accounting for browser overhead. Sequential processing gives up some throughput to reduce peak memory and make progress predictable.
Practical operating limits
There is no universal “maximum folder.” A modern desktop with ample memory can handle more records and larger files than a phone. Browser extensions, other tabs, filesystem speed, and whether the files are local or on a network volume also matter.
| Symptom | Likely pressure | Response |
|---|---|---|
| Slow initial table | Very high file count | Select a narrower top-level folder and export in sections |
| Tab becomes unresponsive during hash | Large candidate file or low memory | Keep the 256 MB guard, close other tabs, hash a smaller folder |
| Export pauses | Large serialized inventory | Use CSV, reduce scope, or export by folder |
| Network volume stalls | File reads depend on remote storage | Copy candidates locally before verification if policy permits |
Choose scope before performance tuning
The safest optimization is not a faster hash loop; it is a smaller, clearly defined question. Audit the active project, then the archive, rather than selecting an entire home directory. A focused scope also produces a report that is easier to review and less likely to expose unrelated filenames.
Measure with the exact folder
The published demo checks correctness and interface behavior. It cannot predict performance for your media archive because its “files” are synthetic metadata records rather than gigabytes of real content. Test with a non-sensitive copy, observe memory use, and stop if the browser becomes unstable.