@@ -16,7 +16,7 @@ and so it means the PR to include the triage details in TWiR can be merged short
16
16
before publication. This time is also shortly before the weekly Rust compiler
17
17
meeting, where the results are looked at.
18
18
19
- ## Generating the Report
19
+ ## Generating the report
20
20
21
21
First, check the previous triage log entry. Look for responses in PRs, and
22
22
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
25
25
the revision range from that triage period. The noted final commit ` $PARENT ` will
26
26
be the parent commit that we use for the current round of triage.
27
27
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:
32
29
33
30
```
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
35
32
```
36
33
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
-
50
34
## Analysis
51
35
52
36
The following is a list of items you should look for when interpreting performance results.
53
37
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.
58
41
59
- ### Viewing Results
42
+ ### Viewing results
60
43
61
44
Look for significant changes (regressions or improvements) in the following:
62
45
- instruction count
@@ -79,7 +62,7 @@ Understanding the comparison page:
79
62
benchmarks. Clicking on the percentages will open a more specific detail view
80
63
of timing for queries run during compilation.
81
64
82
- ### Interpreting Results
65
+ ### Interpreting results
83
66
84
67
* Warning* : max rss is much more variable than instruction count. Recheck the "Absolute
85
68
data" checkbox otherwise the noise becomes unmanageable.
@@ -103,11 +86,6 @@ Single PR in Merge:
103
86
regression, consider requesting the author revert their changes. It may
104
87
be worth looking through the comments to see if any perf CI runs were done,
105
88
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.
111
89
112
90
Difficult cases: the merge was a rollup of multiple PRs.
113
91
- 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.
122
100
that are likely to affect performance.
123
101
- Add an entry to the triage log, as for the easy cases.
124
102
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
+
125
108
### This Week in Rust
126
109
127
110
Once finished, file a PR adding a link to the log entry in [ This Week in
128
111
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.
135
113
136
114
If you have any questions, the ` t-compiler/performance ` stream on Zulip is the
137
115
best place to ask.
0 commit comments