ARROW-10696: [C++] Add SetBitRunReader#8770
Conversation
|
ArrayRangeEquals benchmarks: |
|
Parquet benchmarks: |
fd9d34f to
b470888
Compare
|
Also some speedups on no-null filters:
(couldn't run a diff because of ARROW-10738) |
b470888 to
fc434dc
Compare
fc434dc to
6ec79cc
Compare
|
Aggregation benchmarks: |
6ec79cc to
ad4b49b
Compare
wesm
left a comment
There was a problem hiding this comment.
This makes sense to me -- definitely nice to see the code simplification in various places and the performance improvements. The no-nulls code paths in filtering for example had seemed inelegant to me but this will make it easier to write the "visit all the set bits" code paths easier to write and maintain in the future.
I don't know if the handful of Parquet writing perf regressions are worth investigating but they do not look too serious
There was a problem hiding this comment.
| if (num_zeros < 64) { | |
| if (ARROW_PREDICT_FALSE(num_zeros < 64)) { |
There was a problem hiding this comment.
IMHO, this is much easier to read as if (num_zeros >= 64) { remaining_ -= 64; continue; } // rest
There was a problem hiding this comment.
| if (num_ones < 64) { | |
| if (ARROW_PREDICT_FALSE(num_ones < 64)) { |
There was a problem hiding this comment.
Well, depending on the distribution of input bits, this may be commonly true (same for the other comment above).
A specialized bitmap reader that yields runs of set bits, for use cases where reset bits (e.g. null bits) don't need any handling. On some use cases it can be significantly faster than the alternatives.
ad4b49b to
2be8572
Compare
A specialized bitmap reader that yields runs of set bits, for use cases where reset bits (e.g. null bits) don't need any handling.
On some use cases it can be significantly faster than the alternatives.