adriangb opened a new pull request, #10550: URL: https://github.com/apache/arrow-rs/pull/10550
# Which issue does this PR close? None. This is benchmark coverage split out of https://github.com/apache/arrow-rs/pull/10549 so that the performance change proposed there can be reviewed against benchmarks that already exist on `main`. # Rationale for this change The existing `DELTA_BYTE_ARRAY` writer benchmarks (added in https://github.com/apache/arrow-rs/pull/10512) write 128 values of 2 MiB each against the default 1 MiB `data_page_size_limit`. Every value exceeds the limit, so each one is cut onto its own data page, and each page boundary clears the encoder's previous-value state. Every prefix length is therefore 0. Measured on `main`, writing that benchmark's own `large_string_shared_prefix` data (256 MiB raw input): | encoding | data_page_size_limit | output | | --- | --- | --- | | PLAIN | default (1 MiB) | 256.02 MiB | | DELTA_BYTE_ARRAY | default (1 MiB) | 256.02 MiB | | DELTA_BYTE_ARRAY | 4 MiB | 2.00 MiB | At the default limit the `DELTA_BYTE_ARRAY` output is byte-for-byte what `PLAIN` produces — the encoding is doing no work, so those benchmarks cannot measure anything about prefix scanning. That is the known regression https://github.com/apache/arrow-rs/issues/10489. The new benchmarks use 1 KiB values, far below the page limit, so roughly 1000 values share a page and the previous-value state survives across them. That is the regime `DELTA_BYTE_ARRAY` is actually deployed in. # What changes are included in this PR? Three new criterion benchmark groups in `bench_small_delta_byte_array_writers`, each writing 8192 rows of 1 KiB strings with both `PLAIN` (as a control/baseline) and `DELTA_BYTE_ARRAY`: - `small_string_shared_prefix` — values differ only in a trailing 8-byte counter, so each prefix scan covers nearly the whole value. - `small_string_partial_prefix` — values share their first 512 bytes and then diverge, the realistic sorted-column case (paths, URLs, keys). Uses a new `create_string_partial_prefix_bench_batch` helper. - `small_string_distinct` — values differ from byte 0, so prefix deduplication saves nothing. No library code is touched. # Are these changes tested? These are benchmarks. The benchmark binary compiles, and `cargo fmt` and `cargo clippy -p parquet --benches --all-features -- -D warnings` pass. The benchmarks were also run, to confirm they resolve real differences rather than noise. They were validated by measuring an actual candidate change against them — the block-wise shared-prefix scan in https://github.com/apache/arrow-rs/pull/10549 — on an A/B/A schedule (baseline, branch, baseline again) so that machine drift is quantified rather than assumed. The `plain` rows act as controls, since `PLAIN` never calls the prefix scan. Times are means in ms, aarch64: | bench | base (pre) | candidate change | base (post) | | --- | --- | --- | --- | | small_string_shared_prefix/plain (control) | 0.683 | 0.694 | 0.699 | | small_string_shared_prefix/delta_byte_array | 2.832 | 0.682 | 2.870 | | small_string_partial_prefix/plain (control) | 0.603 | 0.853 | 0.639 | | small_string_partial_prefix/delta_byte_array | 1.876 | 0.703 | 1.925 | | small_string_distinct/plain (control) | 0.454 | 0.471 | 0.474 | | small_string_distinct/delta_byte_array | 0.680 | 0.710 | 0.699 | The shared-prefix case resolves a 4.2x difference and the partial-prefix case a 2.7x difference, both far above the largest control excursion. The distinct case is flat, which is the correct outcome — there is no prefix to scan there. One caveat: the `small_string_partial_prefix/plain` control had a single noisy reading (0.853 against baselines of 0.603 and 0.639), so that row's noise floor is wider than the others; the delta effect on that bench is still several times larger than that excursion. The baseline columns also show that on `main` the shared-prefix case costs 2.83 ms with `DELTA_BYTE_ARRAY` versus 0.68 ms with `PLAIN` — the encoding is currently about 4x more expensive than `PLAIN` on exactly the data it exists for. # Are there any user-facing changes? No. Benchmark-only change; no library code is touched. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
