adriangb commented on PR #10745: URL: https://github.com/apache/arrow-rs/pull/10745#issuecomment-5344990190
### Benchmarks vs `main` on the standalone head (`525a659`, merge-base `505afcb`) For reviewers: this PR alone against `main`, on the GKE runner (`c4a-highmem-16`). Full `arrow_writer` five times (three on the previous standalone head `477a393`, same diff, plus two on the current one — a third died at start on a Kubernetes `BackoffLimitExceeded`), the delta-byte-array subset three times, and a main-vs-main control of each, so every number has an "identical code on the same job type" column next to it. Runs: full [1](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5337331144) [2](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5337333595) [3](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5337394280) [4](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5344904392) [5](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5344915440), controls [a](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5337404259) [b](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5344929545); filtered [1](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5343642890) [2](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5343644841) [3](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5343646091), [control](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5343684653). **What moves, in the same direction in all five full runs:** | benchmark | per run | mean | controls | |---|---|---|---| | `large_string_non_null/default` | −5.7 / −8.4 / −12.5 / −13.7 / −5.2 | **−9.1%** | +0.7, +3.2 | | `large_string_non_null/parquet_2` | −5.9 / −8.0 / −12.5 / −13.4 / −6.0 | **−9.2%** | −0.5, +2.4 | | `large_string_non_null/zstd` | −5.7 / −7.8 / −12.5 / −14.1 / −5.4 | **−9.1%** | −1.1, +1.6 | | `large_string_non_null/zstd_parquet_2` | −5.7 / −8.2 / −12.5 / −13.4 / −7.7 | **−9.5%** | −0.9, +1.8 | | `large_string_non_null/bloom_filter` | −5.0 / −7.2 / −10.0 / −11.2 / −7.6 | **−8.2%** | −0.1, +1.9 | | `medium_string_shared_prefix_nullable/delta_byte_array` | −7.9 / −2.8 / −4.9 / −6.2 / −4.0 | −5.2% | −3.7, −2.2 | `large_string_non_null` is 1024 × 256 KiB values with default properties: a page holds several mini-batches of large values, so the running min/max already covers most of them and the per-mini-batch copy was pure overhead. That is the general shape this change targets — large values, pages holding more than one mini-batch. **What does not move:** the over-limit `DELTA_BYTE_ARRAY` benches (`large_string_shared_prefix*`, `large_string_distinct*`, 2 MiB values against the 1 MiB page limit) are flat vs `main`: −0.8 … +3.7% means, inside controls of ±7…11% on this job type. Expected — on `main` every such value already opens its own page (the bug #10505 fixes), `flush_data_page` takes the running min/max on every mini-batch, and both copies happen regardless. Once #10505 is in they become the big winners: stacked on #10554 this change measures **−22 … −24%** on `large_string_shared_prefix*/delta_byte_array` and −5% on `large_string_distinct_nullable` ([three runs + control](https://github.com/apache/arrow-rs/pull/10745#issuecomment-5339165212)). **Nothing negative.** The only two benches that read positive in all five runs are `primitive_sparse_99pct_null/cdc` (+4.6%, controls +2.6 / +1.0 — a primitive column, this file is not on its path) and `string_and_binary_view/default` (+3.1%, controls +1.4 / +1.6); both sit on their controls, and the change can only remove work (same comparison as before, then ≤ the copies it used to make unconditionally). Everything else in the ~200-bench suite is inside what the two main-vs-main controls move on identical code (`list_primitive/parquet_2` +18.1, `string_ree/default` +19.6, `string_non_null/default` −12.5 on the control). -- 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]
