Skip to content

Commit 73783d9

Browse files
Merge pull request #908 from rylev/remove-python-script
Remove triage python report
2 parents 86f6aca + a6f1295 commit 73783d9

File tree

4 files changed

+14
-416
lines changed

4 files changed

+14
-416
lines changed

.github/workflows/ci.yml

Lines changed: 0 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -128,9 +128,6 @@ jobs:
128128
- name: Build collector
129129
run: cargo build -p collector
130130

131-
- name: Test automated triage
132-
run: sh -x -c "ci/check-triage-script.sh"
133-
134131
- name: Check benchmarks
135132
run: sh -x -c "ci/check-profiling.sh"
136133

ci/check-triage-script.sh

Lines changed: 0 additions & 30 deletions
This file was deleted.

triage/README.md

Lines changed: 14 additions & 36 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ and so it means the PR to include the triage details in TWiR can be merged short
1616
before publication. This time is also shortly before the weekly Rust compiler
1717
meeting, where the results are looked at.
1818

19-
## Generating the Report
19+
## Generating the report
2020

2121
First, check the previous triage log entry. Look for responses in PRs, and
2222
follow up on any promised actions. (i.e. nag people!)
@@ -25,38 +25,21 @@ While looking at the previous triage log entry, take note of the final commit in
2525
the revision range from that triage period. The noted final commit `$PARENT` will
2626
be the parent commit that we use for the current round of triage.
2727

28-
Start the new triage log entry in a new file using a `YYYY-MM-DD.md`-form name.
29-
Follow the format of the previous entries.
30-
31-
Use the provided script to automate building the file:
28+
Use the API endpoint to automate building the file:
3229

3330
```
34-
% ./weekly-report.py PARENT > YYYY-MM-DD.md
31+
% curl https://perf.rust-lang.org/perf/triage '{"start":"$PARENT","stat":"instructions:u"}' > YYYY-MM-DD.md
3532
```
3633

37-
### Manual Generation
38-
39-
You can also build the report manually, starting by viewing the [perf website](https://perf.rust-lang.org).
40-
41-
- Determine the revision range. The start revision corresponds to the end
42-
revision from the previous log entry. The end revision is the latest measured
43-
revision on perf.rust-lang.org.
44-
- Set the range on the graphs by setting the "start" and "end" revisions at
45-
the top of the page. Full SHAs must be used.
46-
- Uncheck the "Absolute data" checkbox, because that makes changes easier to
47-
see.
48-
- Record the revision range, with a link, in the log entry.
49-
5034
## Analysis
5135

5236
The following is a list of items you should look for when interpreting performance results.
5337

54-
If you've generated a triage report, you will go through each entry in the report
55-
and verify that it is properly labeled as a regression, improvement, or a mix
56-
of the two. For instance, some entries that are labeled as regressions, are actually
57-
not regressions and have only been labeled as such due to noise.
38+
Go through each entry in the report and verify that it is properly labeled as a regression,
39+
improvement, or a mix of the two. For instance, some entries that are labeled as regressions,
40+
are actually not regressions and have only been labeled as such due to noise.
5841

59-
### Viewing Results
42+
### Viewing results
6043

6144
Look for significant changes (regressions or improvements) in the following:
6245
- instruction count
@@ -79,7 +62,7 @@ Understanding the comparison page:
7962
benchmarks. Clicking on the percentages will open a more specific detail view
8063
of timing for queries run during compilation.
8164

82-
### Interpreting Results
65+
### Interpreting results
8366

8467
*Warning*: max rss is much more variable than instruction count. Recheck the "Absolute
8568
data" checkbox otherwise the noise becomes unmanageable.
@@ -103,11 +86,6 @@ Single PR in Merge:
10386
regression, consider requesting the author revert their changes. It may
10487
be worth looking through the comments to see if any perf CI runs were done,
10588
and whether the regression was expected.
106-
- If you did not generate the triage report, add an entry.
107-
Include the PR title and number, a link to the PR comment you added mentioning the
108-
performance effect, and a link to the performance results. Include useful details,
109-
such as the size of the regression/improvement, and any promises of follow-up action
110-
from authors in the case of a regression.
11189

11290
Difficult cases: the merge was a rollup of multiple PRs.
11391
- Look through the PRs and try to determine which was the cause. Often you
@@ -122,16 +100,16 @@ Difficult cases: the merge was a rollup of multiple PRs.
122100
that are likely to affect performance.
123101
- Add an entry to the triage log, as for the easy cases.
124102

103+
### Add analysis and follow-ups to report
104+
105+
- For each entry in the report, include useful details, such as the size of the regression/improvement, and any promises of follow-up action
106+
from authors in the case of a regression.
107+
125108
### This Week in Rust
126109

127110
Once finished, file a PR adding a link to the log entry in [This Week in
128111
Rust](https://github.com/emberian/this-week-in-rust/).
129-
- Add it within the "Updates from Rust Core" section.
130-
- Add a "Rust Compiler Performance Triage" subsection immediately after the
131-
list of notable merged PRs.
132-
- Within that subsection, add a list containing a single item.
133-
- That item should be a link to the triage log entry with the form
134-
"YYYY-MM-DD", possibly with some brief text about notable things.
112+
- See the previous This Week in Rust edition for how the log entry should be formatted.
135113

136114
If you have any questions, the `t-compiler/performance` stream on Zulip is the
137115
best place to ask.

0 commit comments

Comments
 (0)