IN LIST: reduce bitmap allocations#23136
Conversation
Replaces HashSet<u8> with a 32-byte stack-allocated bitmap. Provides O(1) membership testing via bit-shifting, significantly reducing memory overhead and improving cache locality. Triggers for UInt8 arrays.
|
run benchmark in_list_strategy |
4cd24c1 to
7408fb5
Compare
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/in-list-in-place-buffers (7408fb5) to 60c407c (merge-base) diff using: in_list_strategy File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagein_list_strategy — base (merge-base)
in_list_strategy — branch
File an issue against this benchmark runner |
…e-buffers # Conflicts: # datafusion/physical-expr/src/expressions/in_list/primitive_filter.rs # datafusion/physical-expr/src/expressions/in_list/static_filter.rs
|
run benchmark in_list_strategy |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing codex/in-list-in-place-buffers (500eccd) to d0f8c34 (merge-base) diff using: in_list_strategy File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: CPU Details (lscpu)Details
Resource Usagein_list_strategy — base (merge-base)
in_list_strategy — branch
File an issue against this benchmark runner |
|
no obvious wins hwere, so closing it down |
Which issue does this PR close?
Rationale for this change
I noticed we were allocating new bitmaps in the InLIst operations when we may not have to .
Attempt to Avoid extra bitmap allocations while building IN LIST static-filter results.
What changes are included in this PR?
Are these changes tested?
by CI
Are there any user-facing changes?
performance