Alamb/test bin op5

[alamb]

Which issue does this PR close?

• Follow on to
• Alamb/test bin op4 #9072

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

[alamb]

run benchmark boolean_kernels

[alamb-ghbot]

🤖 ./gh_compare_arrow.sh gh_compare_arrow.sh Running
Linux aal-dev 6.14.0-1018-gcp #19~24.04.1-Ubuntu SMP Wed Sep 24 23:23:09 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Comparing alamb/test_bin_op5 (d697357) to 2d6fc51 diff
BENCH_NAME=boolean_kernels
BENCH_COMMAND=cargo bench --features=arrow,async,test_common,experimental --bench boolean_kernels
BENCH_FILTER=
BENCH_BRANCH_NAME=alamb_test_bin_op5
Results will be posted here when complete

[alamb-ghbot]

🤖: Benchmark completed

Details

group            alamb_test_bin_op5                     main
-----            ------------------                     ----
and              1.00    207.8±0.75ns        ? ?/sec    1.31    272.9±1.02ns        ? ?/sec
and_sliced_1     1.00  1101.2±18.47ns        ? ?/sec    1.00  1097.7±12.97ns        ? ?/sec
and_sliced_24    1.03    246.9±1.44ns        ? ?/sec    1.00    240.3±0.62ns        ? ?/sec
not              1.00    145.9±0.54ns        ? ?/sec    1.00   146.5±10.38ns        ? ?/sec
not_slice_24     1.00    193.5±0.91ns        ? ?/sec    1.01    195.2±2.14ns        ? ?/sec
not_sliced_1     1.00    619.7±4.18ns        ? ?/sec    1.00   622.0±13.20ns        ? ?/sec
or               1.00    198.9±3.57ns        ? ?/sec    1.28    254.1±2.50ns        ? ?/sec
or_sliced_1      1.00  1114.1±12.81ns        ? ?/sec    1.10  1230.3±19.40ns        ? ?/sec
or_sliced_24     1.02    247.6±3.05ns        ? ?/sec    1.00    242.3±3.34ns        ? ?/sec

[alamb]

Since the new optimized from_bitwise_binary_op may call op outside of the set bits, we need to avoid also trying to count the ones within the first pass.

[alamb]

Note to self: I made a nullif benchmark locally, and it seems as if counting bits during the application actually does make a small difference

nullif no-nulls mask(10%)
                        time:   [208.47 ns 209.97 ns 211.22 ns]
                        change: [+6.4142% +7.1611% +7.9491%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 11 outliers among 100 measurements (11.00%)
  6 (6.00%) low severe
  2 (2.00%) low mild
  2 (2.00%) high mild
  1 (1.00%) high severe

nullif no-nulls mask(10%, sliced)
                        time:   [242.71 ns 244.30 ns 245.68 ns]
                        change: [+4.9678% +5.8756% +6.8006%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 9 outliers among 100 measurements (9.00%)
  6 (6.00%) low severe
  3 (3.00%) low mild

nullif no-nulls mask(1%)
                        time:   [220.58 ns 222.91 ns 225.16 ns]
                        change: [+10.834% +12.034% +13.361%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 10 outliers among 100 measurements (10.00%)
  7 (7.00%) low severe
  2 (2.00%) low mild
  1 (1.00%) high severe

nullif nulls mask(10%)  time:   [213.91 ns 215.16 ns 216.23 ns]
                        change: [+4.9421% +5.7045% +6.4951%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 10 outliers among 100 measurements (10.00%)
  4 (4.00%) low severe
  6 (6.00%) low mild

nullif nulls mask(10%, sliced)
                        time:   [253.58 ns 255.72 ns 257.57 ns]
                        change: [+3.2081% +4.1105% +4.9077%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 10 outliers among 100 measurements (10.00%)
  6 (6.00%) low severe
  4 (4.00%) low mild

nullif nulls mask(1%)   time:   [224.66 ns 226.45 ns 227.95 ns]
                        change: [+7.8770% +8.8461% +9.8628%] (p = 0.00 < 0.05)
                        Performance has regressed.
Found 12 outliers among 100 measurements (12.00%)
  7 (7.00%) low severe
  5 (5.00%) low mild

[alamb]

Broken into other prs

• Add nullif_kernel benchmark #9089

Closing this PR in favor of #9090