seen Set is half the scan; forks re-mint dir rowsindex/tridex.js:101:zw-109 dedupes postings through a JS Set: on git.git the
serial blob scan is 43.3 s, of which tri.mint is 29.0 s = trisOf 6.8 s +
seen probe/add 21.0 s + tix.put 1.06 s, and the Set is 344 MB of the 470
MB RSS. 2.14 M of its 2.36 M entries are the FILE slot, where every probe is a
guaranteed miss (trisOf dedupes within the blob, each path is minted once).
Under --fork each worker re-mints the shared dir-prefix rows: 2.36 M puts
serial -> 2.70 M at 4 -> 2.90 M at 8 (+23%), though the fold is verified
identical to serial. Found in the 2026-09-18 index review.
Drop the file slot from seen; dedupe dir slots with a per-prefix
Uint8Array(1<<15) trigram bitmap (32 KB per live prefix). Expected 43 s ->
23 s serial, RSS 470 -> 130 MB, and SEEN_MAX's reset goes away.
The dedupe state is now a Map of slot -> Uint8Array(1<<15), one bitmap per live dir prefix; the file slot is put unasked. The lane dedupes the puts that the Set used to swallow, so the ROW SET is byte-identical (git.git: 2362004 rows before and after, the fixture's 322 rows serial and at --fork 2) while the put count rises 2362004 -> 2451331 (+3.8%): those are hl12 collisions between two file slots at one depth, or a file and a dir slot, that the Set deduped and the bitmap cannot see. Worst case the bitmaps are 3 * 4096 * 32 KB = 384 MB; git.git holds 196 such prefixes (6 MB), linux 2402 (75 MB). Forked workers still re-mint the shared dir rows (330 puts serial, 335 at --fork 2 on the fixture, before and after): the stripe is by PATH hash (BEE-072:26:r_), so files of one dir land on different workers, and no bitmap crosses a process. Fixing that needs a prefix-aligned stripe, which is gritzko's call.
git clone --shared is no good for a bench: the runtime refuses
a repo that borrows objects through objects/info/alternates, so
the bench clone is a plain local (hardlinked) one.