zeroshade opened a new pull request, #958:
URL: https://github.com/apache/arrow-go/pull/958
### Rationale for this change
The `Benchmarks` workflow runs `go test -bench=. ./...` sequentially across
every
package. Because `go test`'s `-timeout` is applied per package, the
wall-clock time
is the sum over all packages — recent `main` runs have taken roughly 3.3
hours
(198–208 min).
### What changes are included in this PR?
Split the benchmark run so it can be parallelized, then combine the results
into a
single upload:
- **`ci/scripts/bench.sh`** — adds `--run` (benchmark a subset of packages,
writing
raw output to a `.dat`) and `--aggregate` (merge one or more `.dat` files
into a
single `bench_stats.json` via `gobenchdata`) modes. The existing
`bench.sh <dir> [--json|-json]` interface is unchanged, so nothing else
that calls
it needs to change.
- **`ci/scripts/bench_shard.sh`** (new) — prints a GitHub Actions matrix
that buckets
the packages containing benchmarks into N shards.
- **`.github/workflows/benchmark.yml`** — reworked into three jobs: `setup`
(compute
the shard matrix) → `benchmark` (matrix; each shard runs its packages and
uploads
its `.dat`) → `combine` (download all `.dat`, aggregate into one
`bench_stats.json`,
and — only on push to `main` — upload once to Conbench).
- **`ci/scripts/bench_adapt.py`** — reuses an existing `bench_stats.json`
(produced by
`combine`) instead of re-running the whole suite.
Because the shards are merged into one JSON and uploaded once, Conbench
still sees a
single run (no `run_id` fragmentation).
### Are these changes tested?
Locally:
- `shellcheck` clean on both scripts; `actionlint` clean on the workflow;
`py_compile`
OK on `bench_adapt.py`.
- Verified the split→merge end to end: ran `--run` on two packages, then
`--aggregate`
produced one `bench_stats.json` containing both suites, in the exact shape
`bench_adapt.py` consumes.
- The legacy `bench.sh <dir> --json` path still runs → aggregates → cleans
up.
Opened as a **draft** to exercise the reworked workflow in CI end to end (it
triggers
on changes to these files).
### Are there any user-facing changes?
No. This only touches CI / benchmark tooling.
### Notes / follow-ups
- Sharding is currently round-robin by package, not runtime-weighted, so a
single
shard can hold two heavy packages (e.g. `arrow/compute` +
`parquet/internal/encoding`)
and become the long pole. The per-package `-timeout` (40m) remains the
hard floor for
any single package. Once this runs, per-shard timings can seed a
runtime-weighted
split or tune the shard count.
--
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]
