perf : avoided repeated bounds checks in take kernel - #10441
Open
Rich-T-kid wants to merge 2 commits into
Open
Conversation
Rich-T-kid
force-pushed
the
rich-t-kid/avoid-take-bounds-checks
branch
from
July 27, 2026 02:28
6b46564 to
1e0e5a4
Compare
Jefffrey
reviewed
Jul 27, 2026
| let columns = record_batch | ||
| .columns() | ||
| .iter() | ||
| .map(|c| take(c, indices, None)) |
Contributor
There was a problem hiding this comment.
i thought None = doesnt check bounds? since default on TakeOptions would set check_bounds to false
so this change actually introduces the check where it was previously absent?
Contributor
Author
There was a problem hiding this comment.
ah I must have missed this https://docs.rs/arrow-select/59.1.0/src/arrow_select/take.rs.html#93
Contributor
Author
|
I may have mis-understood #8879 then. |
alamb
changed the title
take kernel
alamb
pushed a commit
that referenced
this pull request
Jul 27, 2026
# Which issue does this PR close? <!-- We generally require a GitHub issue to be filed for all bug fixes and enhancements and this helps us generate change logs for our releases. You can link an issue to this PR using the GitHub syntax. --> - works towards #8879. # Rationale for this change see #8879 (comment) the point of these benchmarks are to measure the change of #10441 <!-- Why are you proposing this change? If this is already explained clearly in the issue then this section is not needed. Explaining clearly why changes are proposed helps reviewers understand your changes and offer better suggestions for fixes. --> # What changes are included in this PR? adds benchmarks for `take_record_batch()` . <!-- There is no need to duplicate the description in the issue here but it is sometimes worth providing a summary of the individual changes in this PR. --> # Are these changes tested? n/a <!-- We typically require tests for all PRs in order to: 1. Prevent the code from being accidentally broken by subsequent changes 2. Serve as another way to document the expected behavior of the code If tests are not included in your PR, please explain why (for example, are they covered by existing tests)? If this PR claims a performance improvement, please include evidence such as benchmark results. --> # Are there any user-facing changes? no <!-- If there are user-facing changes then we may require documentation to be updated before approving the PR. If there are any breaking changes to public APIs, please call them out. -->
Contributor
|
Update to get #10442 |
Contributor
|
run benchmarks take_kernels |
|
🤖 Arrow criterion benchmark running (GKE) | trigger CPU Details (lscpu)Comparing rich-t-kid/avoid-take-bounds-checks (5656bd2) to 25569a3 (merge-base) diff File an issue against this benchmark runner |
|
🤖 Arrow criterion benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagebase (merge-base)
branch
File an issue against this benchmark runner |
Contributor
Author
yup like @Jefffrey mentioned this actually adds an extra validation step so there isn't much performance gains. maybe what #8879 was referring to was actually the bounds checks in each of the |
Rich-T-kid
force-pushed
the
rich-t-kid/avoid-take-bounds-checks
branch
from
July 27, 2026 19:05
5656bd2 to
c27953d
Compare
Rich-T-kid
force-pushed
the
rich-t-kid/avoid-take-bounds-checks
branch
from
July 27, 2026 19:06
c27953d to
1a626c5
Compare
Contributor
Author
local benchmarks for https://github.com/apache/arrow-rs/commit/1a626c58c524e30c945937be9baeac73932abad5
compared to `main`
the latest commit adds 5 unsafe blocks but they are all within loops which is causing a nice perf boost. this avoids the length check |
Jefffrey
reviewed
Jul 28, 2026
| // SAFETY: idx is a valid index in indices.nulls() --> idx<indices.len() | ||
| if values.value(unsafe { indices.value_unchecked(idx).as_usize() }) { | ||
| // SAFETY: caller guarantees all valid indices are in-bounds | ||
| if unsafe { values.value_unchecked(indices.value_unchecked(idx).as_usize()) } { |
Contributor
There was a problem hiding this comment.
im not sure we can do this, since callers can call take without an unsafe block and with check bounds off and pass in an invalid index; this would cause UB via safe interfaces i believe?
Contributor
There was a problem hiding this comment.
I agree -- though it might be faster to validate the indices once at the start of take_impl and then use the unchecked accessors
We could also potentially add a take_unchecked variant or something to skip the acces check
Contributor
Author
aah, I think ive come full circle to understand what @Dandandan meant in
I can update the PR to introduce a new unsafe method that uses unsafe array access methods. The main issue with this would be the code bloat. |
Contributor
Author
|
out of curiosity could you run the benchmarks @Jefffrey. if the perf difference is < +10% This may not even be worth it |
Contributor
|
run benchmark take_kernels |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
🤖 Arrow criterion benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagebase (merge-base)
branch
File an issue against this benchmark runner |
alamb
reviewed
Jul 28, 2026
alamb
left a comment
alamb
left a comment
Contributor
There was a problem hiding this comment.
Thanks for pushing on this @Rich-T-kid
Contributor
|
10% performance on |
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?
takekernels #8879.Rationale for this change
see #8879 (comment) and #8879 (comment)
What changes are included in this PR?
instead of checking length bound for each array we only do this for the first array and then remaining arrays avoid validation. The rational behind this is that record batches are all of the same size.
Are these changes tested?
logically nothing has changed
Are there any user-facing changes?
no