Resampling performance improvement and sparse aggregation columns support

[IvoDD]

Reference Issues/PRs

Monday ref: 11679866800

Depends on PRs #3091 and #3110

Issues

• There is complicated bucket hopping logic in three places: generate_output_index_column, generate_resampling_output_column, SortedAggregator::aggregate
• The bucket hopping logic involves many branches with loads of checks

Changes (split per commit for easier review)

0. Adds C++ benchmarks which measures the CPU intensive part of resampling
1. Pure move of the generate_output_index_column to sorted_aggregation.cpp.
   • This way all bucket hopping logic is in one place.
2. Construct a ResampleMapping in generate_output_index_column and use it directly in other methods.
   • ResampleMapping just has a mapping from output_row to (start_column_index, start_column_offset), (end_column_index, end_column_offset).
   • Resolves the 3 places with similar logic.
   • Makes the implementation of sparse aggregation easier.
3. Use galloping search in generate_output_index_column to skip past all rows in a single bucket at once.
   • Index column construction was the bottleneck: aggregation vectorises well but index iteration does not.
   • Changes complexity from O(num_input_rows + num_buckets) to O(num_buckets × log(rows_per_bucket)).
   • Always ≤ O(num_input_rows + num_buckets) even when num_buckets ≥ num_input_rows.
4. Preallocate the output index column to min(num_buckets, num_input_rows) instead of num_buckets.
   • Galloping search has a higher constant than linear scan and regresses at low rows per bucket.
   • Slightly improves the case where most buckets are empty due to smaller allocation.
5. Use a runtime heuristic to choose between linear scan and galloping search.
   • Linear scan is faster below ~32 rows/bucket (because of smaller constant and better branch prediction); galloping search is faster above.
   • Threshold determined empirically from benchmarks at intermediate bucket counts. Extra benchmarking was done with more parametrization of the existing benchmark. Not kept in PR to avoid a huge amount of benchmarking code.
   • Recovers the Dense-100k and Empty regressions from commit 3 while retaining all gains elsewhere.
6. Implement sparse resampling.
   • Small change made straightforward by the ResampleMapping from commit 2.
   • Minimal overhead for the dense case.

Resample benchmark timings

BM_resample/<rows_per_seg>/<num_segs>/<num_buckets>/<num_cols>. Total rows ~1M.
Source: cpp/arcticdb/processing/test/benchmark_resample.cpp. Times in ms, --benchmark_min_time=2s.

Regime	Args	rows/bucket	Description
Dense-1k	100k × 10, 1k buckets	~1000	Many rows/bucket, single row-slice
Dense-100	100k × 10, 10k buckets	~100	Medium rows/bucket, single row-slice
Dense-10	100k × 10, 100k buckets	~10	Few rows/bucket, single row-slice
Spanning	2k × 500, 100 buckets	~10k	Buckets span multiple row-slices
Empty	100k × 10, 10M buckets	<1	Bucket smaller than row spacing; most empty

1 aggregation column

#	Change	D-1k	D-100	D-10	Spanning	Empty
0	Baseline	1.27	1.34	1.47	1.65	11.1
1	Code move	1.02 (−20%)	1.12 (−16%)	1.27 (−14%)	1.40 (−15%)	11.1 (0%)
2	ResampleMapping	1.02 (−20%)	1.12 (−16%)	1.32 (−10%)	1.40 (−15%)	11.8 (+6%)
3	Galloping search	0.059 (−95%)	0.385 (−71%)	2.94 (+100%)	0.285 (−83%)	21.9 (+97%)
4	Bounded allocation	0.058 (−95%)	0.396 (−70%)	2.91 (+98%)	0.291 (−82%)	21.5 (+94%)
5	Heuristic (lin/EUB)	0.059 (−95%)	0.383 (−71%)	1.27 (−14%)	0.293 (−82%)	11.5 (+4%)
6	Sparse-input support	0.068 (−95%)	0.449 (−66%)	1.28 (−13%)	0.296 (−82%)	11.5 (+4%)

100 aggregation columns

#	Change	D-1k	D-100	D-10	Spanning	Empty
0	Baseline	1.37	1.43	1.56	6.22	48.0
1	Code move	1.11 (−19%)	1.18 (−17%)	1.34 (−14%)	5.92 (−5%)	46.2 (−4%)
2	ResampleMapping	1.11 (−19%)	1.19 (−17%)	1.39 (−11%)	5.87 (−6%)	50.4 (+5%)
3	Galloping search	0.148 (−89%)	0.471 (−67%)	2.96 (+90%)	4.65 (−25%)	63.1 (+31%)
4	Bounded allocation	0.148 (−89%)	0.480 (−66%)	2.95 (+89%)	4.67 (−25%)	44.1 (−8%)
5	Heuristic (lin/EUB)	0.149 (−89%)	0.477 (−67%)	1.33 (−15%)	4.70 (−24%)	35.9 (−25%)
6	Sparse-input support	0.158 (−88%)	0.537 (−62%)	1.35 (−13%)	4.94 (−21%)	36.0 (−25%)

Deltas vs baseline (row 0).

Notes on benchmark results

• Load average varied across runs so there are some artifacts in results like "Code move" improvements.
• Galloping search improves the speed when there are more rows in a single bucket significantly. Thorough benchmarking showed exponential upper bound (EUB) becomes faster than linear search at ~32 rows per bucket. Hence we see some performance regressions in the 10 rows per bucket and in the mostly empty bucket cases.
• Bounded allocation mostly helps the empty case as expected
• Using the heuristic to choose between EUB and linear search helps when rows_per_bucket < 32. It is even more efficient than the baseline due to slightly better branch prediction (improved use of ARCTICDB_LIKELY and ARCTICDB_UNLIKELY).
• Final state: every regime at or faster than baseline; Dense 1000 rows per bucket is the biggest winner with 20x improvement; Mostly empty bucket is the only usecase with no improvement and remains around baseline (+4%)

[claude]

ArcticDB Code Review Summary

Delta since last review is a single commit (89d9fd8 "Address Alex comments") touching cpp/arcticdb/processing/sorted_aggregation.cpp and cpp/arcticdb/processing/test/test_resample.cpp. The accumulate refactor, multiplication-based threshold (avoiding division by zero), and added comments are all correct improvements over the previous code. No new issues introduced.

PR Title and Description

• Typo "aggragation" -> "aggregation" fixed in title.

Documentation

• Sparse resampling support still not reflected in technical docs: docs/claude/cpp/PROCESSING.md and docs/claude/python/QUERY_PROCESSING.md describe resampling but do not mention that sparse aggregation columns are now supported. The previously-thrown "Cannot aggregate sparse column" schema error has been removed (and the corresponding test_resampling_sparse_data deleted), so a brief note that sparse aggregation columns are now supported would keep the docs aligned with behaviour.
• No user-facing doc or tutorial mention of the new sparse resampling capability. Optional but worth considering before release.

Notes (no action required)

• Multiplication form total_input_rows < linear_scan_threshold * num_buckets is mathematically equivalent to the old total_input_rows / num_buckets < linear_scan_threshold for realistic inputs; overflow would require more than 5e17 buckets, so not a practical concern.
• Removing the post-advance_boundary_past_value re-check of current_bucket.contains(it->value()) in generate_output_index_column is safe because advance_boundary_past_value always lands bucket_end_it on a bucket whose half-open interval contains the probed value for both LEFT- and RIGHT-closed boundaries. The previous defensive re-check was redundant.
• This PR is stacked on binary-search-utils-optimization and depends on PRs Binary search utils #3091 and Optimize binary search methods #3110 - merge order matters.