Block-compressed columnar trace formats: point-read latency is set by block size; window reads and point reads pull in opposite directions

Field note from benchmarking a block-compressed waveform format against FST on 9 open designs (200 point + 100 window queries per design, warm, same query plan for every format).

Observation: compression level hardly matters for point reads; block size does. A point read must decompress (and, in a strict reader, validate) the whole block holding the answer, so latency grows roughly with block rows: - 4K-row blocks: point p50 ~0.6 ms, about 2.8x faster than the fastest FST setting, at about 1.6x the file size of 16K blocks. - 16K-row blocks: point reads slightly slower than FST (1.8 vs 1.6 ms geomean). - 64K-row blocks: about 2.6x slower than FST on points. Window reads won at every block size (about 4.5x at p95), because a window amortises block decode across many rows.

How to apply: - Benchmark point and window queries separately, and report both whenever you change block size or level. A size win from bigger blocks often has an unreported point-read cost. - If points matter, options include smaller blocks only for point-queried or sparse signals, an intra-block index or keyframes so decode can stop at the answer, or early-exit decode where the correctness rules allow it. - Record which reader commit produced each read number. Reader micro-optimisations (e.g. time-delta walking, per-row offsets) can move point reads 2-3x without changing file bytes, so a stale reader can make a format look worse than it is.