Repository navigation
Perf: Improve dictionary slice concatenation - #12008
Rich-T-kid wants to merge 1 commit into
Conversation
|
run benchmark concatenate_kernels |
|
🤖 Benchmark starting (GKE) | trigger Target: concatenate_kernels Sharding factor: 1 (1 workers). Comparing codex/dictionary-concat-slices (90cbf31) to bf0cde3 (merge-base) diff Run configurationrun benchmark concatenate_kernels
shards: 1
Results will be posted when all workers finish. File an issue against this benchmark runner |
|
🤖 Benchmark failed or incomplete (GKE) | trigger Target: concatenate_kernels Comparing codex/dictionary-concat-slices (90cbf31) to bf0cde3 (merge-base) diff Run configurationrun benchmark concatenate_kernels
shards: 1
Errors / missing shardsPer-runner informationconcatenate_kernels — shard 1/1Node: gk3-benchmark-cluster-nap-bch756b4-46b2a638-fvcz Instance: c4a-highmem-16 (12 vCPU / 65 GiB) uname: BENCH_COMMAND: cargo bench --features=arrow,async,test_common,experimental,object_store --bench concatenate_kernelsCPU Details (lscpu)Resource UsageNo completed measurement resource samples. File an issue against this benchmark runner |
|
The controlled DataFusion end-to-end run is complete: results. Using DataFusion #26816 with every Arrow crate pinned to either The queries expected to concatenate sliced dictionary group keys improved most:
No spill occurred on either side. |
|
should have marked this a draft |
|
run benchmark concatenate_kernel |
|
🤖 Benchmark starting (GKE) | trigger Target: concatenate_kernel Sharding factor: 1 (1 workers). Comparing codex/dictionary-concat-slices (90cbf31) to bf0cde3 (merge-base) diff Run configurationrun benchmark concatenate_kernel
env:
BENCH_FILTER: dict
shards: 1
Results will be posted when all workers finish. File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Target: concatenate_kernel Comparing codex/dictionary-concat-slices (90cbf31) to bf0cde3 (merge-base) diff Run configurationrun benchmark concatenate_kernel
env:
BENCH_FILTER: dict
shards: 1
DetailsPer-runner informationconcatenate_kernel — shard 1/1Node: gk3-benchmark-cluster-nap-1h5f9ztd-949bd8ae-9fwn Instance: c4a-highmem-16 (12 vCPU / 65 GiB) uname: BENCH_COMMAND: cargo bench --features=arrow,async,test_common,experimental,object_store --bench concatenate_kernelCPU Details (lscpu)Resource Usagebase (merge-base)
branch
File an issue against this benchmark runner |
90cbf31 to
32f0197
Compare
|
@CuteChuanChuan could you take a look |
|
I had ai run some benchmarks with this pr as the tip in datafusion and the results look good #12008 (comment). I think it may be worth adding targeted benchmarks here just so we can choose a correct threshold as 16x may be too conservative. |
Which issue does this PR close?
Closes #11885
Why is this change needed?
Slicing a dictionary array only slices its keys; it still retains the full values array. When concat or interleave merges short slices from large dictionaries, the current code builds a mask and key mapping for every dictionary value, including values that no selected row references. The work therefore scales with the full dictionary instead of the number of output rows.
What changes are included in this PR?
When a dictionary has more than 16 values per selected row, collect only the referenced keys and store the old-to-new key mappings sparsely. Smaller dictionaries continue using the existing dense mask and vector mapping. Both concat and interleave use this shared dictionary merge path.
Are these changes tested?
Tests cover concat and interleave of short slices backed by large dictionaries, sparse key remapping, null keys, and the existing dense path.
The consolidated benchmark coverage, including the ratio sweep for evaluating the 16x cutoff, is in #12054.
Are there any significant user-facing changes?
No. This only changes how dictionary values are merged internally.