perf(arrow-select) : rename generic bound & avoid bounds check in take_primitive

[Rich-T-kid]

#10945
#10944 <- here

Which issue does this PR close?

• second to last piece of Reduce bound checks in take kernels #8879.

Rationale for this change

The take kernel uses a const generic VALIDATE_INDICES: bool (previously CHECKED,5c8afaf) to control whether index bounds are validated. Threading this through internal helpers like take_native and take_union_type_ids allows callers who have already validated their indices to skip redundant bounds checks, and enables a new take_record_batch_unchecked API (seperate PR,).

What changes are included in this PR?

• Renamed the const generic parameter from CHECKED to VALIDATE_INDICES across all internal take functions for clarity
• Threaded VALIDATE_INDICES into take_native and take_union_type_ids, with the false branch using get_unchecked in the no-null path.

Are these changes tested?

Yes, existing tests in arrow-select cover the take kernel. The unchecked path shares the same logic as the checked path

Are there any user-facing changes?

nope

[Rich-T-kid]

run benchmark take_kernel

[adriangbot]

🤖 Arrow criterion benchmark running (GKE) | trigger
Instance: c4a-highmem-16 (12 vCPU / 65 GiB) | Linux bench-c5498435298-2064-9kcl4 6.12.94+ #1 SMP Fri Jul 17 09:42:57 UTC 2026 aarch64 GNU/Linux

CPU Details (lscpu)

Architecture:                            aarch64
CPU op-mode(s):                          64-bit
Byte Order:                              Little Endian
CPU(s):                                  16
On-line CPU(s) list:                     0-15
Vendor ID:                               ARM
Model name:                              Neoverse-V2
Model:                                   1
Thread(s) per core:                      1
Core(s) per cluster:                     16
Socket(s):                               -
Cluster(s):                              1
Stepping:                                r0p1
BogoMIPS:                                2000.00
Flags:                                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache:                               1 MiB (16 instances)
L1i cache:                               1 MiB (16 instances)
L2 cache:                                32 MiB (16 instances)
L3 cache:                                80 MiB (1 instance)
NUMA node(s):                            1
NUMA node0 CPU(s):                       0-15
Vulnerability Gather data sampling:      Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit:             Not affected
Vulnerability L1tf:                      Not affected
Vulnerability Mds:                       Not affected
Vulnerability Meltdown:                  Not affected
Vulnerability Mmio stale data:           Not affected
Vulnerability Reg file data sampling:    Not affected
Vulnerability Retbleed:                  Not affected
Vulnerability Spec rstack overflow:      Not affected
Vulnerability Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:                Mitigation; __user pointer sanitization
Vulnerability Spectre v2:                Mitigation; CSV2, BHB
Vulnerability Srbds:                     Not affected
Vulnerability Tsa:                       Not affected
Vulnerability Tsx async abort:           Not affected
Vulnerability Vmscape:                   Not affected

Comparing rich-T-kid/thread-unsafe-checks-against-const-generic (f2d6a4c) to 27a6a40 (merge-base) diff

Run configuration

run benchmark take_kernel

BENCH_COMMAND=cargo bench --features=arrow,async,test_common,experimental,object_store --bench take_kernel
Results will be posted here when complete

---

File an issue against this benchmark runner

[adriangbot]

Benchmark for this request failed before finishing (Kubernetes reason: BackoffLimitExceeded).

Benchmarks requested: take_kernel

Kubernetes message

Job has reached the specified backoff limit

---

File an issue against this benchmark runner

[Rich-T-kid]

benchmarks shows a minor 3-4% improvement when I ran this locally with array sizes 8192. this PR serves as the final step for #10945

[Rich-T-kid]

run benchmark take_kernel

[adriangbot]

🤖 Arrow criterion benchmark running (GKE) | trigger
Instance: c4a-highmem-16 (12 vCPU / 65 GiB) | Linux bench-c5499303497-2067-7nn2t 6.12.94+ #1 SMP Fri Jul 17 09:42:57 UTC 2026 aarch64 GNU/Linux

CPU Details (lscpu)

Architecture:                            aarch64
CPU op-mode(s):                          64-bit
Byte Order:                              Little Endian
CPU(s):                                  16
On-line CPU(s) list:                     0-15
Vendor ID:                               ARM
Model name:                              Neoverse-V2
Model:                                   1
Thread(s) per core:                      1
Core(s) per cluster:                     16
Socket(s):                               -
Cluster(s):                              1
Stepping:                                r0p1
BogoMIPS:                                2000.00
Flags:                                   fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 sm3 sm4 asimddp sha512 sve asimdfhm dit uscat ilrcpc flagm sb paca pacg dcpodp sve2 sveaes svepmull svebitperm svesha3 svesm4 flagm2 frint svei8mm svebf16 i8mm bf16 dgh rng bti
L1d cache:                               1 MiB (16 instances)
L1i cache:                               1 MiB (16 instances)
L2 cache:                                32 MiB (16 instances)
L3 cache:                                80 MiB (1 instance)
NUMA node(s):                            1
NUMA node0 CPU(s):                       0-15
Vulnerability Gather data sampling:      Not affected
Vulnerability Indirect target selection: Not affected
Vulnerability Itlb multihit:             Not affected
Vulnerability L1tf:                      Not affected
Vulnerability Mds:                       Not affected
Vulnerability Meltdown:                  Not affected
Vulnerability Mmio stale data:           Not affected
Vulnerability Reg file data sampling:    Not affected
Vulnerability Retbleed:                  Not affected
Vulnerability Spec rstack overflow:      Not affected
Vulnerability Spec store bypass:         Mitigation; Speculative Store Bypass disabled via prctl
Vulnerability Spectre v1:                Mitigation; __user pointer sanitization
Vulnerability Spectre v2:                Mitigation; CSV2, BHB
Vulnerability Srbds:                     Not affected
Vulnerability Tsa:                       Not affected
Vulnerability Tsx async abort:           Not affected
Vulnerability Vmscape:                   Not affected

Comparing rich-T-kid/thread-unsafe-checks-against-const-generic (f2d6a4c) to 27a6a40 (merge-base) diff

Run configuration

run benchmark take_kernel

BENCH_COMMAND=cargo bench --features=arrow,async,test_common,experimental,object_store --bench take_kernel
Results will be posted here when complete

---

File an issue against this benchmark runner

[adriangbot]

Benchmark for this request failed before finishing (Kubernetes reason: BackoffLimitExceeded).

Benchmarks requested: take_kernel

Kubernetes message

Job has reached the specified backoff limit

---

File an issue against this benchmark runner

[Jefffrey]

benchmarks shows a minor 3-4% improvement when I ran this locally with array sizes 8192. this PR serves as the final step for #10945

are we sure this isnt noise? from what i see in this PR, the generic isnt actually being threaded in to be false anywhere

also side note, i do wonder the impact of this on codegen. i know we introduced it in previous PRs, but @alamb did raise a recent epic (in datafusion) about binary size, and this is likely to contribute to a larger binary now if we thread in false for the generic (though to what degree im not sure)

• [EPIC] Reduce binary size datafusion#24727

just something to think about 🤔

[Rich-T-kid]

are we sure this isnt noise? from what i see in this PR, the generic isn't actually being threaded in to be false anywhere

this is true, it could be noise. when I ran the benchmarks locally I did switch out the true for false before/after running the benchmarks to compare

just something to think about 🤔

I will keep this in mind. I think seeing the performance difference between the two variants will give us the best guide on weather or not its worth introducing the extra code. #10945 should have this once I can get the benchmarks bot working