You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an existing `benchcomp` script to measure Kani's performance in
CI, but it is prone to noise and only focuses on the end-to-end
performance of compilation and verification together, leaving a need for
more granular measurements.
This script focuses solely on changes in the runtime of the Kani
compiler and runs with warm ups, repeats and outlier detection (based on
the rust compiler's method in
[`rustc-perf`](https://github.com/rust-lang/rustc-perf)) in an attempt
to limit noise. The new `compile-timer-short` CI job uses this script on
a subset of the `perf` tests (currently excluding `s2n-quic`,
`kani-lib/arbitrary` & `misc/display-trait`) to produce a
`benchcomp`-like table comparing the compiler performance per-crate
before and after a given commit.
This also modifies our auto-labeller to ensure end-to-end benchmarks
(like `benchcomp`) and the new compiler-specific ones are only run when
the parts of Kani that they profile have changed.
We manually tested the CI job on my personal fork (see [this regressing
run](https://github.com/AlexanderPortland/kani/actions/runs/15788016660?pr=6)
from a test PR that intentionally slows down the compiler).
Resolves#2442
By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
0 commit comments