bench: add date_part benchmark#23350
Conversation
| ) | ||
| } | ||
|
|
||
| fn generate_date64_array(rng: &mut ThreadRng) -> Date64Array { |
There was a problem hiding this comment.
Nice addition. One small thought: Date64Array values are milliseconds since epoch, but this generator uses 0..30_000, so every value lands within the first 30 seconds of 1970-01-01. That still exercises the Date64 branch, but the calendar-part benchmarks like year, month, week, and day may be less representative than Date32.
Could be worth generating something like days * SEC_DAY * 1_000, or another millisecond date range, so Date64 measures more realistic date extraction work.
There was a problem hiding this comment.
Good catch, updated them using the same set of constants.
| } | ||
|
|
||
| fn criterion_benchmark(c: &mut Criterion) { | ||
| let mut rng = rand::rng(); |
There was a problem hiding this comment.
Small benchmark hygiene suggestion: the data is regenerated from ThreadRng on each run. That can make Criterion comparisons a bit noisier when looking into regressions.
Using a seeded StdRng would keep the benchmark data stable across runs.
There was a problem hiding this comment.
Switched to StdRng. I believe ThreadRng in other tests should also be replaced with a seeded generator - maybe later
3 participants
Which issue does this PR close?
date_partUDF optimisations #23351Rationale for this change
date_partUDF and other datetime functions have non-trivial logic and should be benchmarkedWhat changes are included in this PR?
Brand new bench for
date_part. Covers a lot of code paths and input combinationsAre these changes tested?
I've run it locally; it passes.
Are there any user-facing changes?