Ryan Levick
Ryan Levick
The following is a user story outlining (my opinion) on an ideal medium-term experience for what PR authors and reviewers should expect to go through when it comes to assessing...
When testing a regressed rollup, we may want to enqueue more than one build at a time. However, this is not possible because of a constraint on the database ([found...
https://github.com/rust-lang/rustc-perf/pull/1377 removed the round trip testing for the database due to it taking a *very* long time (and just timing out). This test can be useful though, so we should...
In https://github.com/rust-lang/rustc-perf/pull/1181 @Kobzol mentions that we are at the limit of even what Vue2 can offer us on the compare page. This is despite the fact that most other pages...
The triage report has improved, but its focus is largely on highlighting single changes impacts on the performance of the Rust compiler. We should think more holistically about what we...
When we add new benchmarks, we typically don't run them on old artifacts, but we could (at least to a certain point in history). While this might not bring a...
The compiler performance team is largely focused on performance changes on a per pull request basis. The procedures we have in place today are largely focused on ensuring that individual...
Currently we return a 502 on panics with no information about what we wrong. We should instead return 500s with the line number where the panic occurred.
We've updated most of the code to refer to the terminology defined in the glossary docs, but all public facing options, APIs, etc, use older terminology. This is naturally much...
The perf process is in flux, but that's even more reason to document that latest state of things. We currently only really document the triage process, but the perf management...