Skip to content

OnPair: decode straight into the builder's byte storage - #9100

Draft
robert3005 wants to merge 1 commit into
rk/zstd-append-to-builderfrom
rk/onpair-decode-into-builder
Draft

OnPair: decode straight into the builder's byte storage#9100
robert3005 wants to merge 1 commit into
rk/zstd-append-to-builderfrom
rk/onpair-decode-into-builder

Conversation

@robert3005

Copy link
Copy Markdown
Contributor

Rationale for this change

  • Closes: #000

What changes are included in this PR?

What APIs are changed? Are there any user-facing changes?

Same shape as the FSST change: `append_to_builder` staged the decoded heap in a
temporary buffer before copying it in. `OnPairDecodePlan` hoists the code
window, the dictionary view, the per-row lengths and the total decoded size out
of `onpair_decode_bytes` so the decode can target the builder's spare capacity
via `append_decoded`, leaving one prefix sum over the lengths as the only work
beyond the bulk `try_decode_into`.

`decode_into` is `#[inline(always)]`: `try_decode_into` is generic over the
dictionary view and only specializes its batched copy loop once inlined into the
caller, so leaving the wrapper out of line costs ~2.5x.

Also extends the Arrow export benchmarks to cover OnPair alongside the other
string encodings, plus nullable variants and the two `append_to_builder`
benchmarks that reach an encoding's specialization directly — the Arrow export
cannot stand in for those, since `execute_until` canonicalizes a bare
FSST/OnPair/Zstd root before any builder sees it.

Signed-off-by: Robert Kruszewski <robert@spiraldb.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant