perf(arrow): build constant filter masks with BooleanBuffer instead of Vec<bool>

[anoopj]

What changes are included in this PR?

The predicate converter builds all-true and all-false boolean masks with BooleanArray::from(vec![b; n]), which allocates an n-byte Vec and then bit-packs it into the array. BooleanBuffer::new_set/new_unset write the packed bits directly, skipping the throwaway Vec and the pack pass.

Covers the always-true/false predicates and the initial accumulators for is_in / not_in, built once per batch. Output is identical (all-set/all-unset, no nulls). Isolated construction is ~125x faster at 8192 rows; the real per-batch win is smaller since this is a fraction of filter evaluation.

Profiling

Isolated construction, release build, 2M iterations with warmup, on an
Apple M4. Each iteration observes the whole buffer via
count_set_bits() so the fill can't be elided under inlining/LTO. This is
a conservative floor.

rows	old (Vec<bool>)	new (BooleanBuffer)	speedup
0	~60 ns	~18 ns	~3x
1024	~820 ns	~36 ns	~23x
8192	~5.8-6.3 us	~63-73 ns	~90x

The per-batch win in real filter evaluation is a fraction of this, since
constant-mask construction is one step of many.

Throwaway harness

use std::hint::black_box;
use std::time::Instant;

use arrow_array::{Array, BooleanArray};
use arrow_buffer::BooleanBuffer;

fn old_path(value: bool, len: usize) -> BooleanArray {
    BooleanArray::from(vec![value; len])
}

fn new_path(value: bool, len: usize) -> BooleanArray {
    let buffer = if value {
        BooleanBuffer::new_set(len)
    } else {
        BooleanBuffer::new_unset(len)
    };
    BooleanArray::new(buffer, None)
}

fn bench<F: Fn(bool, usize) -> BooleanArray>(name: &str, len: usize, iters: u64, f: F) {
    for _ in 0..1000 {
        black_box(f(black_box(true), black_box(len)).values().count_set_bits());
    }
    let start = Instant::now();
    for i in 0..iters {
        let arr = f(black_box(i & 1 == 0), black_box(len));
        // Observe the whole buffer so the fill can't be elided under inlining/LTO.
        black_box(arr.values().count_set_bits());
    }
    let per_iter = start.elapsed().as_nanos() as f64 / iters as f64;
    println!("{name:<28} len={len:<6} {per_iter:>10.2} ns/iter");
}

fn main() {
    let iters = 2_000_000u64;
    for len in [0usize, 1024, 8192] {
        bench("old (Vec<bool>)", len, iters, old_path);
        bench("new (BooleanBuffer)", len, iters, new_path);
        println!();
    }
}

Are these changes tested?

Added test_constant_bool_array

[Fokko]

Nice one @anoopj This makes sense to me 👍

[mbutrovich]

Thanks @anoopj!

[laskoviymishka]

Nice optimization, going straight to a bit-packed BooleanBuffer instead of allocating a Vec<bool> and packing it is the right move, and it's output-identical to the old path at every batch size, empty included. No objection to the approvals.

I left a couple of non-blocking notes inline: the four construction sites are formatted inconsistently now (cargo fmt will want to collapse two of them), and none of these paths has a direct test to catch a future new_set/new_unset swap. Neither needs to hold this.

The one thing I'd ask for the perf claim itself — there's no benchmark in the diff, so could we link the profiling run, or drop in a small criterion bench, in the PR body? Makes the ~200x easy to defend the next time we bump Arrow. Not a blocker.

All minor. Will wait for some time before merging, to others to weigh in.

[laskoviymishka]

Small thing — these two helper sites got written multi-line while the r#in/not_in accumulator sites are single-liners, and at this indent they're only 80 chars, so cargo fmt will want to collapse them to match.

Since all four sites now repeat the same new_set/new_unset idiom, a tiny private constant_bool_array(n: usize, value: bool) -> BooleanArray would unify them and sidestep the formatting question entirely. wdyt?

[anoopj]

That is a good idea. I aded a helper function as you suggested.

[laskoviymishka]

These is_in/not_in accumulator seeds (and the always_true/always_false paths) aren't run against a batch by any test that asserts the output, so a swapped new_set/new_unset — or an n=0 regression — would pass silently.

Since the whole point here is output-identical behavior, I'd add a small test over a zero-row and a nonzero batch asserting the values are the expected constant and null_count() is zero. Cheap guard for a path that's easy to get subtly wrong on a future edit.

[anoopj]

Added test_constant_bool_array to do the assertion.

[anoopj]

@laskoviymishka Thanks for the review. Updated the PR description with the details of perf run. I didn't commit the bench since it didn't seem worth it.

[laskoviymishka]

🌬️ ⛵