adriangb commented on PR #10549: URL: https://github.com/apache/arrow-rs/pull/10549#issuecomment-5183527631
## Benchmark summary — three independent runs Consolidating the three runs above. Baseline is https://github.com/apache/arrow-rs/pull/10550 (`a5444d23`), changed is this branch (`2404f178`); the two differ by exactly the one prefix-scan commit. Run on a dedicated `c4a-highmem-16` (Neoverse-V2, aarch64) per run. Note the runner labels the baseline column `main` — the Run configuration block in each comment confirms it used the #10550 SHA, not `main`. Ratios are baseline time / branch time, so higher means this PR is faster: | bench | run 1 | run 2 | run 3 | | | --- | --- | --- | --- | --- | | `small_string_shared_prefix/delta_byte_array` | **3.65x** | **3.67x** | **3.75x** | faster | | `small_string_partial_prefix/delta_byte_array` | **2.42x** | **2.46x** | **2.53x** | faster | | `small_string_distinct/delta_byte_array` | 1.01x | 1.01x | 1.03x | flat | | `small_string_shared_prefix/plain` (control) | 1.02x | 1.02x | 1.01x | flat | | `small_string_partial_prefix/plain` (control) | 1.01x | 1.04x | 1.01x | flat | | `small_string_distinct/plain` (control) | 1.00x | 1.03x | 1.03x | flat | The three `plain` rows are controls: `PLAIN` goes through `FallbackEncoderImpl::Plain` and never calls `common_prefix_length`, so it runs identical code on both sides. All three stayed within 1-4% across all runs, which is the noise floor. `small_string_distinct/delta_byte_array` is also flat, as expected — those values differ from byte 0, so there is no shared prefix to scan and nothing to speed up. The two real effects are 2.4-2.5x and 3.65-3.75x, well clear of that floor, and the spread across three runs is under 3% on each. ### One thing worth pulling out Absolute times for the shared-prefix column, run 2: | | `PLAIN` | `DELTA_BYTE_ARRAY` | | --- | --- | --- | | baseline | 1069 us | 3700 us | | this PR | 1069 us | 1000 us | On the baseline, `DELTA_BYTE_ARRAY` is ~3.5x *more expensive* than storing the values in full, on exactly the data the encoding exists for. With this change it comes in slightly faster than `PLAIN`, which is what you would expect given it also writes far fewer bytes. -- 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]
