[arrow-select] Replace ArrayData with direct Array construction in filter kernels#9986
[arrow-select] Replace ArrayData with direct Array construction in filter kernels#9986liamzwbao wants to merge 3 commits into
ArrayData with direct Array construction in filter kernels#9986Conversation
ArrayData with direct Array constructionArrayData with direct Array construction in filter
ArrayData with direct Array construction in filterArrayData with direct Array construction in filter kernels
|
run benchmark filter_kernels |
|
🤖 Arrow criterion benchmark running (GKE) | trigger CPU Details (lscpu)Comparing issue-9298-repalce-array-data-arrow-select (34b1837) to accb1cf (merge-base) diff File an issue against this benchmark runner |
alamb
left a comment
There was a problem hiding this comment.
Thank you @liamzwbao -- this is great. It is hard not to love a PR that:
- Makes the code simpler (fewer lines)
- Removes uses of
unsafe - Make things faster
I left a few stylistic comments and am running the benchmarks. Assuming the benchmark results look good I think this PR is good to merge
Thank you again
| let (null_count, nulls) = filter_null_mask(nulls, predicate)?; | ||
| let buffer = BooleanBuffer::new(nulls, 0, predicate.count); | ||
|
|
||
| Some(unsafe { NullBuffer::new_unchecked(buffer, null_count) }) |
There was a problem hiding this comment.
can we please add a safety comment here explaining why this is safe:
| Some(unsafe { NullBuffer::new_unchecked(buffer, null_count) }) | |
| // Safety: null_count return from filter_null_mas is correct | |
| Some(unsafe { NullBuffer::new_unchecked(buffer, null_count) }) |
It might also be nice to add a debug assert here to verify in debug builds
debug_assert_eq!(null_count, nulls.num_zeros())| .len(predicate.count) | ||
| .add_buffer(filter.dst_offsets.into()) | ||
| .add_buffer(filter.dst_values.into()); | ||
| let offsets = unsafe { OffsetBuffer::new_unchecked(filter.dst_offsets.into()) }; |
There was a problem hiding this comment.
Here it would also be nice to comment about why this is safe (what assumptions it relies on). However, I see the existing code doesn't have a safety comment
// Safety: offsets are correctly constructed| predicate: &FilterPredicate, | ||
| ) -> GenericByteViewArray<T> { | ||
| let new_view_buffer = filter_native(array.views(), predicate); | ||
| let views = ScalarBuffer::new(new_view_buffer, 0, predicate.count); |
There was a problem hiding this comment.
Here (and other places) you can probably use the unchecked variants too to skip some checks, if we need to get additional speed (ScalarBuffer::new_unchecked)
However, given your PR removes an allocation (the buffers array) I suspect this is already going to be faster and avoiding unsafe is a nice bonus ❤️
| } | ||
|
|
||
| /// Filters `nulls` and reuses the computed `null_count` to avoid scanning the bitmap. | ||
| fn filter_nulls(nulls: Option<&NullBuffer>, predicate: &FilterPredicate) -> Option<NullBuffer> { |
There was a problem hiding this comment.
What do you think about making this a method on FilterPredicate? That would make it easier to find / reuse I think.
impl FilterPredicate {
fn filter_nulls(&self, nulls: Option<&NullBuffer>) -> Option<NullBuffer> {
...
}
}|
🤖 Arrow criterion benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagebase (merge-base)
branch
File an issue against this benchmark runner |
|
@liamzwbao -- some of these results look great but some look like they got slightly slower. Can you investigate (perhaps by using |
|
run benchmark filter_kernels |
|
🤖 Arrow criterion benchmark running (GKE) | trigger CPU Details (lscpu)Comparing issue-9298-repalce-array-data-arrow-select (34b1837) to accb1cf (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 |
|
🤔 hmm that run #9986 (comment) looks very good. Will run another |
|
run benchmark filter_kernels |
|
🤖 Arrow criterion benchmark running (GKE) | trigger CPU Details (lscpu)Comparing issue-9298-repalce-array-data-arrow-select (34b1837) to accb1cf (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 |
|
I would say the benchmarks don't show a clear win / downside one way or the other I do think it would be good to avoid the new checks just to be sure but otherwise this PR is ready to go. Thank you again |
Which issue does this PR close?
ArrayDatawith direct Array construction, when possible #9298.Rationale for this change
What changes are included in this PR?
ArrayDataBuilderpaths inarrow-select/src/filter.rswith direct typed array constructors.Are these changes tested?
Covered by exsiting tests
Are there any user-facing changes?
No