[tamirms]

A popular term's bitmap is read whole for every page that touches it: on
pubnet chunk 6410 the fifteen most popular terms are 250 KiB to 1.08 MiB
each, so a popular page reads about 9 MB of index to answer from a few
slabs of it. And index.pack's 128-entry records make its tail follow the
term count, which no fixed first read covers on big chunks, so every open
there pays a second round trip.

A term whose serialized bitmap is over 64 KiB is now stored as one entry
per slab of the chunk, zero-length where it has no events, and LookupKeys
reads only the slabs the window reaches and reports their span as
covered. The app data names the split terms after the chunk's slab
count, one 8-byte row of slot and fingerprint each, and the blob has an
exact length. The stamp keeps its version, since nothing has shipped:
index packs written before this change have to be rebuilt. Records close at 16 KiB with no
entry limit, so the tail follows the file size, and Open's first read is
max(64 KiB, 4 bytes per 16 KiB of file), rounded up to 4 KiB.

Every stage of a query after the first now asks for at most 16 slabs
rather than the whole rest of the window. A split term is read only for
a stage's slabs, at most one container per slab, so a query holds at
most 128 KiB of each split term at once whatever the chunk's density,
under 2 MiB for queryEvents' 15-term budget.

When a query has a split term, each stage's answer covers only that
stage's slabs, so the next stage asks for every term again. The cold
reader keeps each whole term it decodes and hands later stages of the
same request that bitmap instead of reading and decoding it again. A
cold reader serves one request, so what it keeps is bounded by that
request's terms, and callers already treat lookup results as
read-only. One request's staged lookups of one split term and 14 whole
terms just under 64 KiB, with the files in the page cache, took 1.0 ms
and allocated 3 MiB instead of 3.3 ms and 15 MiB on 156 slabs (pubnet
density, 11 stages), and 4.4 ms and 10 MiB instead of 33 ms and
115 MiB on 916 slabs (six times that density, 58 stages).

Measured on gp3 with a cold page cache, against the code before this
change: five popular terms over four slabs took 1.8 ms p50 instead of
11.9 ms on a pubnet chunk folded to seven times its density, and 12 ms
instead of 118 ms with eight query streams each reading its own copy. A
rare term took 3.0 ms instead of 5.3 ms on sac-6000, whose tail now fits
one read. A read of a split term's whole chunk rebuilds the term from
its slab entries, about 0.5 ms more CPU per term on the folded chunk
than decoding one whole bitmap.

A page that never fills, on the folded chunk with its 16 most popular
terms paired so that they never occur together, holds 2.2 MB at a time
rather than 37 MB, and 200 such pages take 0.61 GB of resident memory
rather than 13.9 GB. Alone and warm it takes 96 ms instead of 82 ms;
under load its throughput and total CPU are the same.

🤖 Generated with Claude Code