Repository navigation
bench: add MutableBuffer::extend, enhance MutableArrayData - #11742
Open
neilconway wants to merge 2 commits into
Open
neilconway wants to merge 2 commits into
neilconway wants to merge 2 commits into
Conversation
…ata` benchmarks, with new inputs each iteration `MutableBuffer::extend` had one benchmark, which copies `u32` slices. Add an arrow-buffer benchmark that appends 32Ki items, one `extend` call per chunk, with chunks of 16 or 1024 items on average. It covers these iterator shapes: - copied slices of `u8`, and mapped slices of `u8`, `i32` and `u128`. - an `i32` range. - `repeat_n`. - a `Chain` of two slices. - a `Filter`, whose size hint, unlike the others', is not exact. `mutable_array` only covered `Utf8`. Add `Utf8View` and dictionary cases, with the existing long random slices and with slices of 1 to 8 rows. Every case now starts with room for all the rows it copies, so its time goes to the copies rather than to growing the buffers from 5 rows. `zip_kernels` and `mutable_array` ran every iteration on the same input. The CPU's branch predictor then learns that input's exact sequence of branch outcomes, such as which string views are stored inline or how long each copied run is. A query sees each batch once, so it never gets that benefit, and code that branches on the data looks faster than it would be in a query. On an AMD EPYC Milan server, zipping two arrays of 8192 string views of 3 to 19 bytes with an all-true mask (one copy, with a branch per view on whether it is inline) took about 3 branch misses per call when every call used the same arrays. Cycling through 32 or more pairs of arrays raised that to about 3,400, and the call took 3.4x as long. The predictor memorized up to 32Ki to 64Ki views, depending on the build, and almost none at 128Ki. With lists of 1024 slices of 1 to 8 rows, it memorized up to 8 lists; from 32 lists on, it missed about once per slice. Every data input now changes each iteration, cycling through: - `zip_kernels`: 64 arrays for each array input and 64 masks for each random mask case (512Ki rows). - `mutable_array`: 64 arrays and 64 lists of slices. - `mutable_buffer_extend`: 16 splits of the items into chunks, and 16 arrays of 32Ki items for each case that reads input data (512Ki items). Scalars and the constant masks stay the same on every iteration, as they would across the batches of a query. `mutable_buffer_extend` chunks have random lengths, 1 to 31 or 1 to 2047 items. With fixed lengths, the predictor would learn when each call's loop ends, and a loop that handles several items per pass would never have items left over.
neilconway
changed the title
MutableBuffer::extend and view/dictionary `MutableArrayD…MutableBuffer::extend, enhance MutableArrayData
mbutrovich
approved these changes
Oct 20, 2026
mbutrovich
left a comment
mbutrovich
left a comment
Contributor
There was a problem hiding this comment.
I already gave these multiple thorough reviews in #11656. Thanks @neilconway!
Rich-T-kid
approved these changes
Oct 20, 2026
Contributor
|
going to merge since these are just benchmarks |
Rich-T-kid
enabled auto-merge
October 20, 2026 16:57
github-actions
Bot
added
the
arrow-core
github-merge-queue
Bot
removed this pull request from the merge queue due to no response for status checks
Oct 21, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Oct 22, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
MutableBuffer::extendfor exact-size iterators #11656, which uses these benchmarks.Rationale for this change
Extend the benchmarks for
MutableBuffer::extendto cover more iterator shapes, and extend theMutableArrayDatabenchmarks to cover more data types. We also revise how data is generated for thezip_kernelsandmutable_arraybenchmarks: the previous approach repeatedly passed the same input data to the functions on every iteration. This allows the branch predictor to do much better than it would on real-world data, which initially hid the ARM regression described above.These improvements are intended to evaluate #11656 more accurately.
What changes are included in this PR?
mutable_buffer_extendbenchmark that appends 32Ki items, oneextendcall per chunk, with chunks of random length (16 or 1024 items on average). It covers copied and mapped slices, ani32range,repeat_n, aChainof two slices, and aFilter, whose size hint is not exact.Utf8Viewand dictionary cases tomutable_array, with the existing long random slices and with slices of 1 to 8 rows. Every case now starts with room for all the rows it copies, so its time goes to the copies rather than to growing the buffers.zip_kernels,mutable_arrayandmutable_buffer_extendthrough 16 to 64 inputs instead of reusing one. Scalars and the constant masks stay the same, as they would across the batches of a query.Are these changes tested?
Benchmark-only change.
Are there any significant user-facing changes?
No.
AI usage
Claude Code (Opus 5.5), reviewed with Codex (Astra 6.1).