tanmay442 opened a new pull request, #26554:
URL: https://github.com/apache/datafusion/pull/26554
## Which issue does this PR close?
- N/A
## Rationale for this change
The grouped `first_value` and `last_value` accumulator allocates one slot per
group. For a group-by that touches few groups per batch, the work the
accumulator does per batch therefore grows with the number of groups in the
query rather than with the number of rows the batch carries. There is no
benchmark for that shape, so the cost cannot be measured and a change that
reduces it cannot be shown to help.
This pull request adds that benchmark. It changes nothing else.
The benchmark is a separate pull request from the change that uses it, as the
contributor guide suggests, so that the benchmark is in the merge base and
the
benchmark runner has a baseline to pair the new rows against.
## What changes are included in this PR?
One file, `datafusion/functions-aggregate/benches/first_last.rs`. The change
is
purely additive, 234 inserted lines and no deleted line, so the baselines
that
other pull requests compare against are unaffected.
Three cases are added, each for `first_value` and `last_value`:
1. `update_bench_many_groups groups=1000000, touched={64,8192}` allocates a
million groups for the accumulator and touches 64 or 8192 of them per
batch.
The same batch is replayed 100 times, as the other benchmarks in the file
do. After the first iteration the accumulator already holds that batch's
extreme for every group, so only the first iteration writes state. This
isolates the per-batch work that scales with the number of allocated
groups.
It is not a stand-in for a query.
2. `update_bench_many_groups_distinct_batches groups=1000000,
touched={64,8192}` has the same shape but walks through 100 distinct
batches. Batch `b` owns the groups
`[b * groups_touched, (b + 1) * groups_touched)`, so no two batches touch
the same group and the accumulator writes the state of every winner, the
same work a query does when each batch brings new rows. This is the case
to
judge a change to the accumulator by.
3. `update_bench_many_groups_dense groups=100000` is the dense counterpart.
Every batch touches every group, so the per-batch work grows with the
number of groups here too.
The two sparse cases bracket two ends rather than modelling the middle of
anything: one where the groups are all known and only the per-batch
bookkeeping
runs, and one where every group is new and the state is written for every
winner.
Both sparse cases use `BatchSize::PerIteration`. A million-group accumulator
holds about 100 MiB, because `resize_states` creates one `Vec<ScalarValue>`
per
allocated group, and criterion's `SmallInput` keeps `ceil(iters/10)` setup
outputs alive at once. When an earlier revision of this benchmark used
`SmallInput`, the runner reported a peak memory of 501.9 MiB for it.
`PerIteration` keeps one accumulator alive. It
does not change what is timed: the setup runs the same number of times either
way, and only the routine is measured. `iter_batched_ref` is used so that
dropping the accumulator, which is one million small allocations, stays out
of
the timed region.
The performance pull request that uses this benchmark is #26536. Its numbers
will come from a paired run of the benchmark runner, after this one has
merged.
## What is the testing strategy for this PR?
`cargo check -p datafusion-functions-aggregate --benches` compiles the new
benchmarks, and `cargo clippy -p datafusion-functions-aggregate --all-targets
-- -D warnings` is clean.
The cases are new benchmarks in an existing file. They change no behaviour,
so
the existing unit tests and sqllogictest files for this aggregate are
untouched.
The benchmark runner in the project's CI will exercise these cases once this
pull request is merged.
## Are there any user-facing changes?
No. This changes only the benchmark file.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
