You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
perf(bitpacked): hoist per-row bookkeeping out of unpackLoop64 block loop
Inner row body computed seven row-dependent quantities (currWord, nextWord,
shift, remainingBits, currentBits, loMask, hiMask, plus FL_ORDER lookup)
from `row` and `bitWidth` on every iteration. `bitWidth` is constant for
the duration of unpackLoop64, so these only need to be computed once.
For a 10M-row I64 column at bitWidth ~20, this drops 7 × 64 × ~9750 blocks
≈ 4.4M ops out of the hot path. JFR shows BitpackedEncoding$Decoder.unpackLoop64
as the largest visible Java frame (31% of RUNNABLE time on
RustVsJavaReadBenchmark.javaReadVolume).
Pre-compute eight 64-entry int[]/long[] tables at method entry, look up
per row inside the block loop. Inner lane loop body is unchanged
(buf.get / >>> / & / out.set).
Bench (M5, JDK 25, 5 warmup × 3s + 10 measurement × 5s, fork 1):
RustVsJavaReadBenchmark.javaReadVolume
before: 109.319 ± 1.042 ops/s
after: 113.526 ± 1.033 ops/s (+3.8 %)
Error bars don't overlap so the gain is real, just modest. Vector API
rewrite of the inner lane loop (TODO line ~) would be the next material
step; this is a no-risk micro-cleanup pending that work.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
0 commit comments