bench: remove stale `array_expression` benchmark by kumarUjjawal · Pull Request #22143 · apache/datafusion

kumarUjjawal · 2026-05-13T05:00:28Z

Which issue does this PR close?

Closes array_replace benchmark does not exercise the array_replace kernel #22121

Rationale for this change

array_replace.rs already covers array_replace, array_replace_n, and array_replace_all through the public UDF path, and includes the relevant int64 benchmark sizes plus broader nested, string, boolean, and fixed-size-binary cases.

Keeping both benchmark targets would duplicate maintenance and make ownership unclear.

What changes are included in this PR?

This removes the stale array_expression benchmark target.

The dedicated array_replace benchmark remains the single benchmark owner for array replacement performance.

Are these changes tested?

Yes, locally

Are there any user-facing changes?

No

kosiew · 2026-05-14T06:50:19Z

run benchmark array_expression

adriangbot · 2026-05-14T06:53:29Z

🤖 Criterion benchmark running (GKE) | trigger
Instance: c4a-highmem-16 (12 vCPU / 65 GiB) | Linux bench-c4448355355-74-t6knf 6.12.68+ #1 SMP Wed Apr 1 02:23:28 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 fix/array_replace_benchmark_kernel (b993851) to 937dfda (merge-base) diff
BENCH_NAME=array_expression
BENCH_COMMAND=cargo bench --features=parquet --bench array_expression
BENCH_FILTER=
Results will be posted here when complete

File an issue against this benchmark runner

adriangbot · 2026-05-14T07:00:28Z

🤖 Criterion benchmark completed (GKE) | trigger

Instance: c4a-highmem-16 (12 vCPU / 65 GiB)

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

Details

group                                                      fix_array_replace_benchmark_kernel     main
-----                                                      ----------------------------------     ----
array_replace                                                                                     1.00     11.9±0.15ms        ? ?/sec
array_replace_all_int64/list_size: 10, num_rows: 4000      1.00   1689.8±8.33µs        ? ?/sec  
array_replace_all_int64/list_size: 100, num_rows: 10000    1.00      8.6±0.03ms        ? ?/sec  
array_replace_all_int64/list_size: 500, num_rows: 10000    1.00     36.7±0.71ms        ? ?/sec  
array_replace_int64/list_size: 10, num_rows: 4000          1.00   1572.1±7.40µs        ? ?/sec  
array_replace_int64/list_size: 100, num_rows: 10000        1.00      5.5±0.36ms        ? ?/sec  
array_replace_int64/list_size: 500, num_rows: 10000        1.00     18.0±0.39ms        ? ?/sec  
array_replace_n_int64/list_size: 10, num_rows: 4000        1.00   1672.2±8.35µs        ? ?/sec  
array_replace_n_int64/list_size: 100, num_rows: 10000      1.00      5.9±0.21ms        ? ?/sec  
array_replace_n_int64/list_size: 500, num_rows: 10000      1.00     18.1±1.01ms        ? ?/sec

Resource Usage

base (merge-base)

Metric	Value
Wall time	15.0s
Peak memory	4.5 GiB
Avg memory	4.4 GiB
CPU user	6.1s
CPU sys	6.1s
Peak spill	0 B

branch

Metric	Value
Wall time	100.0s
Peak memory	4.6 GiB
Avg memory	4.5 GiB
CPU user	105.4s
CPU sys	14.3s
Peak spill	0 B

File an issue against this benchmark runner

kosiew

@kumarUjjawal
Thanks for working on this. I do not have any blocking concerns, but I left one suggestion around benchmark organization and avoiding duplicate coverage.

kosiew · 2026-05-14T07:00:47Z

+    let four_arg_fields = vec![array_field, from_field, to_field, max_field];

-    // Benchmark array functions
+    let mut group = c.benchmark_group("array_replace_int64");


Nice addition. One thing I noticed is that datafusion/functions-nested/benches/array_replace.rs already contains a dedicated array_replace benchmark covering array_replace_udf, array_replace_n_udf, and array_replace_all_udf across the same int64 sizes, along with nested, string, bool, and fixed-size-binary cases.

It might be worth consolidating this into the dedicated array_replace.rs benchmark, or removing the now somewhat misleading array_expression benchmark target. That would help avoid duplicate benchmark maintenance and keep ownership clearer.

Sounds good, I removed the duplicate array_expression

kosiew

@kumarUjjawal
Thanks for the iteration.

Looks 👍 to me

bench: run array_replace kernels in benchmark

b993851

github-actions Bot added the functions Changes to functions implementation label May 13, 2026

kosiew reviewed May 14, 2026

View reviewed changes

remove stale array_expression benchmark

00e80e9

kumarUjjawal changed the title ~~bench: run array_replace kernels in benchmark~~ bench: remove stale array_expression benchmark May 14, 2026

Merge branch 'main' into fix/array_replace_benchmark_kernel

b655462

kosiew approved these changes May 14, 2026

View reviewed changes

Merge branch 'main' into fix/array_replace_benchmark_kernel

fc49b8b

alamb added this pull request to the merge queue May 14, 2026

Merged via the queue into apache:main with commit 6a57b22 May 14, 2026
36 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

bench: remove stale `array_expression` benchmark#22143

bench: remove stale `array_expression` benchmark#22143
alamb merged 4 commits into
apache:mainfrom
kumarUjjawal:fix/array_replace_benchmark_kernel

kumarUjjawal commented May 13, 2026 •

edited

Loading

Uh oh!

kosiew commented May 14, 2026

Uh oh!

adriangbot commented May 14, 2026

Uh oh!

adriangbot commented May 14, 2026

Uh oh!

kosiew left a comment •

edited

Loading

Uh oh!

kosiew May 14, 2026

Uh oh!

kumarUjjawal May 14, 2026

Uh oh!

kosiew left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

kumarUjjawal commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

kosiew commented May 14, 2026

Uh oh!

adriangbot commented May 14, 2026

Uh oh!

adriangbot commented May 14, 2026

Uh oh!

kosiew left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kosiew May 14, 2026

Choose a reason for hiding this comment

Uh oh!

kumarUjjawal May 14, 2026

Choose a reason for hiding this comment

Uh oh!

kosiew left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

kumarUjjawal commented May 13, 2026 •

edited

Loading

kosiew left a comment •

edited

Loading