Skip to main content
Version: 0.13.0

Benchmark History

Invowk tracks release performance in Bencher. The public history is keyed by release tag, so users can compare published versions such as v0.12.0 and v0.13.0 directly.

Pull request benchmark runs are maintainer guardrails. They can fail a change when Bencher detects a regression, but they are not the user-facing performance history. Pull requests use the same Bencher bare-metal Spec as release runs.

Release Workflow​

The release workflow uploads Bencher Metric Format JSON before publishing the GitHub release:

  • --branch is the release tag, for example v0.13.0.
  • --hash is the release commit SHA.
  • --start-point is the previous release tag when one exists.
  • --start-point-clone-thresholds and --start-point-reset keep release thresholds and history aligned from version to version.
  • --image and --spec make Bencher execute the benchmark command on bare-metal runners, not on the GitHub Actions runner that packaged the image.

Tracked Metrics​

The BMF payload includes the same performance dimensions previously shown in local release assets:

  • CLI startup latency for version, help, command help, and command listing paths.
  • Parser, discovery, module validation, and full pipeline benchmark latency.
  • Go benchmark memory usage and allocation counts.
  • Release build time and stripped binary size.

Maintainer Commands​

Generate local BMF data with:

make bench-bmf

The output is written to artifacts/benchmarks/invowk.bmf.json and can be uploaded with Bencher's json adapter.

CI packages the benchmark source into an OCI image with build/bencher/Dockerfile, logs in to Bencher's registry with BENCHER_API_TOKEN, pushes the image, and then calls bencher run --image ... --spec .... Shared Bencher bare-metal runners do not have network access during benchmark execution, so the image vendors Go dependencies and installs runtime dependencies at image build time.