jayzhan211 commented on code in PR #25285: URL: https://github.com/apache/datafusion/pull/25285#discussion_r4027401678
########## .ai/skills/add-benchmarks/SKILL.md: ########## @@ -0,0 +1,83 @@ +--- +name: add-benchmarks +description: Guidelines for designing or extending DataFusion benchmarks. +--- + +# Benchmark Design + +Follow these guidelines when designing or adding a new benchmark. + +## Design principles + +### Benchmark at a higher level + +Try to move benchmarks to a higher level when possible. For example, prefer SQL +benchmarks even for microbenchmarks of individual operators. When benchmarking a +function, exercise its evaluation path instead of benchmarking internal utility +functions in isolation. + +This makes benchmarks easier to maintain and helps assess how much an optimization +matters to end-to-end runtime. It also helps avoid spending time optimizing code +that accounts for only a small fraction of the total runtime. + +### Vary the key workload axes + +First identify the key axes to vary. For example, for a join benchmark: + +- Input size on each side. +- Join-filter selectivity. +- ... + +Then choose benchmark cases that exercise representative variations. Full +combinatorial coverage is unnecessary; focus on typical workloads that reflect +real use cases. + +When adding benchmark queries, simply tag each query with the decision made +for every axis. For example, for a join benchmark with input sizes/filter selectivity +to tune: + +```sql +-- Q1: Small left input, large right input; 0.1% of pairs match. +SELECT * +FROM generate_series(1, 100) AS l +JOIN generate_series(1, 100000) AS r + ON (l.value + r.value) % 1000 = 0; + +-- Q2: Medium inputs on both sides; no filter. +SELECT * +FROM generate_series(1, 1000) AS l +CROSS JOIN generate_series(1, 1000) AS r; +``` + +## SQL benchmarks + +For implementation details, see the +[SQL benchmark README](../../../benchmarks/sql_benchmarks/README.md). + +1. **Isolate the operator being measured in microbenchmarks.** + + When a microbenchmark targets a specific operator, keep the work done by Review Comment: **Say when criterion benches are still the right tool.** The repo has about 180 criterion bench files. "Prefer SQL benchmarks even for microbenchmarks" with no exceptions will clash with reviews of PRs that touch hashing, row conversion or array kernels, where SQL setup would drown out the code being measured. One sentence would cover it, e.g.: "Use a criterion bench only when the code has no SQL-reachable path, or when per-row costs are too small to see through a query. ########## .ai/skills/add-benchmarks/SKILL.md: ########## @@ -0,0 +1,83 @@ +--- +name: add-benchmarks +description: Guidelines for designing or extending DataFusion benchmarks. +--- + +# Benchmark Design + +Follow these guidelines when designing or adding a new benchmark. + +## Design principles + +### Benchmark at a higher level + +Try to move benchmarks to a higher level when possible. For example, prefer SQL +benchmarks even for microbenchmarks of individual operators. When benchmarking a +function, exercise its evaluation path instead of benchmarking internal utility +functions in isolation. + +This makes benchmarks easier to maintain and helps assess how much an optimization +matters to end-to-end runtime. It also helps avoid spending time optimizing code +that accounts for only a small fraction of the total runtime. + +### Vary the key workload axes + +First identify the key axes to vary. For example, for a join benchmark: + +- Input size on each side. +- Join-filter selectivity. +- ... + +Then choose benchmark cases that exercise representative variations. Full +combinatorial coverage is unnecessary; focus on typical workloads that reflect +real use cases. + +When adding benchmark queries, simply tag each query with the decision made +for every axis. For example, for a join benchmark with input sizes/filter selectivity +to tune: + +```sql +-- Q1: Small left input, large right input; 0.1% of pairs match. +SELECT * +FROM generate_series(1, 100) AS l +JOIN generate_series(1, 100000) AS r + ON (l.value + r.value) % 1000 = 0; + +-- Q2: Medium inputs on both sides; no filter. +SELECT * +FROM generate_series(1, 1000) AS l +CROSS JOIN generate_series(1, 1000) AS r; +``` + +## SQL benchmarks + +For implementation details, see the +[SQL benchmark README](../../../benchmarks/sql_benchmarks/README.md). + +1. **Isolate the operator being measured in microbenchmarks.** + + When a microbenchmark targets a specific operator, keep the work done by Review Comment: **Clear up the tension between the two main rules.** "Benchmark at a higher level" and "isolate the operator" can read as opposite advice. Suggested wording: go in through the highest-level interface (SQL), but keep everything around the operator as cheap as possible. ########## .ai/skills/add-benchmarks/SKILL.md: ########## @@ -0,0 +1,83 @@ +--- +name: add-benchmarks +description: Guidelines for designing or extending DataFusion benchmarks. +--- + +# Benchmark Design + +Follow these guidelines when designing or adding a new benchmark. + +## Design principles + +### Benchmark at a higher level + +Try to move benchmarks to a higher level when possible. For example, prefer SQL +benchmarks even for microbenchmarks of individual operators. When benchmarking a +function, exercise its evaluation path instead of benchmarking internal utility +functions in isolation. + +This makes benchmarks easier to maintain and helps assess how much an optimization +matters to end-to-end runtime. It also helps avoid spending time optimizing code +that accounts for only a small fraction of the total runtime. + +### Vary the key workload axes + +First identify the key axes to vary. For example, for a join benchmark: + +- Input size on each side. +- Join-filter selectivity. +- ... + +Then choose benchmark cases that exercise representative variations. Full +combinatorial coverage is unnecessary; focus on typical workloads that reflect +real use cases. + +When adding benchmark queries, simply tag each query with the decision made +for every axis. For example, for a join benchmark with input sizes/filter selectivity +to tune: + +```sql +-- Q1: Small left input, large right input; 0.1% of pairs match. +SELECT * +FROM generate_series(1, 100) AS l +JOIN generate_series(1, 100000) AS r + ON (l.value + r.value) % 1000 = 0; + +-- Q2: Medium inputs on both sides; no filter. +SELECT * +FROM generate_series(1, 1000) AS l +CROSS JOIN generate_series(1, 1000) AS r; +``` + +## SQL benchmarks + +For implementation details, see the +[SQL benchmark README](../../../benchmarks/sql_benchmarks/README.md). + +1. **Isolate the operator being measured in microbenchmarks.** + + When a microbenchmark targets a specific operator, keep the work done by Review Comment: **Mention expect_plan.** Every nlj query has expect_plan NestedLoopJoinExec. It matters a lot: if an optimizer change turns the NLJ into a hash join, the benchmark keeps "passing" while measuring the wrong operator. I'd make it its own rule: assert the plan shape you mean to measure. -- 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]
