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
Note that final command: it's a doozy! It uses the `cargo rustc`
90
93
command, which executes rustc with (potentially) additional options;
91
94
the `--profile check` and `--lib` options specify that we are doing a
92
-
`cargo check` execution, and that this is a library (not an
93
-
execution).
95
+
`cargo check` execution, and that this is a library (not a binary).
94
96
95
97
At this point, we can use `perf` tooling to analyze the results. For example:
96
98
@@ -110,7 +112,8 @@ can be helpful; it is covered below.
110
112
111
113
### Gathering NLL data
112
114
113
-
If you want to profile an NLL run, you can just pass extra options to the `cargo rustc` command. The actual perf site just uses `-Zborrowck=mir`, which we can simulate like so:
115
+
If you want to profile an NLL run, you can just pass extra options to
116
+
the `cargo rustc` command, like so:
114
117
115
118
```bash
116
119
touch src/lib.rs
@@ -128,26 +131,26 @@ simple but useful tool that lets you answer queries like:
128
131
- "how much time was spent in function F" (no matter where it was called from)
129
132
- "how much time was spent in function F when it was called from G"
130
133
- "how much time was spent in function F *excluding* time spent in G"
131
-
- "what fns does F call and how much time does it spend in them"
134
+
- "what functions does F call and how much time does it spend in them"
132
135
133
136
To understand how it works, you have to know just a bit about
134
137
perf. Basically, perf works by *sampling* your process on a regular
135
138
basis (or whenever some event occurs). For each sample, perf gathers a
136
139
backtrace. `perf focus` lets you write a regular expression that tests
137
-
which fns appear in that backtrace, and then tells you which
140
+
which functions appear in that backtrace, and then tells you which
138
141
percentage of samples had a backtrace that met the regular
139
142
expression. It's probably easiest to explain by walking through how I
140
143
would analyze NLL performance.
141
144
142
-
## Installing `perf-focus`
145
+
###Installing `perf-focus`
143
146
144
147
You can install perf-focus using `cargo install`:
145
148
146
149
```
147
150
cargo install perf-focus
148
151
```
149
152
150
-
## Example: How much time is spent in MIR borrowck?
153
+
###Example: How much time is spent in MIR borrowck?
151
154
152
155
Let's say we've gathered the NLL data for a test. We'd like to know
153
156
how much time it is spending in the MIR borrow-checker. The "main"
@@ -175,7 +178,7 @@ samples where `do_mir_borrowck` was on the stack: in this case, 29%.
175
178
currently executes `perf script` (perhaps there is a better
176
179
way...). I've sometimes found that `perf script` outputs C++ mangled
177
180
names. This is annoying. You can tell by running `perf script |
178
-
head` yourself -- if you see named like `5rustc6middle` instead of
181
+
head` yourself -- if you see names like `5rustc6middle` instead of
179
182
`rustc::middle`, then you have the same problem. You can solve this
180
183
by doing:
181
184
@@ -190,7 +193,7 @@ stdin, rather than executing `perf focus`. We should make this more
190
193
convenient (at worst, maybe add a `c++filt` option to `perf focus`, or
191
194
just always use it -- it's pretty harmless).
192
195
193
-
## Example: How much time does MIR borrowck spend solving traits?
196
+
###Example: How much time does MIR borrowck spend solving traits?
194
197
195
198
Perhaps we'd like to know how much time MIR borrowck spends in the
196
199
trait checker. We can ask this using a more complex regex:
@@ -215,7 +218,7 @@ If you're curious, you can find out exactly which samples by using the
215
218
each sample. The `|` at the front of the line indicates the part that
216
219
the regular expression matched.
217
220
218
-
## Example: Where does MIR borrowck spend its time?
221
+
###Example: Where does MIR borrowck spend its time?
219
222
220
223
Often we want to do a more "explorational" queries. Like, we know that
221
224
MIR borrowck is 29% of the time, but where does that time get spent?
@@ -258,7 +261,7 @@ altogether ("total") and the percent of time spent in **just that
258
261
function and not some callee of that function** (self). Usually
259
262
"total" is the more interesting number, but not always.
260
263
261
-
### Absolute vs relative percentages
264
+
### Relative percentages
262
265
263
266
By default, all in perf-focus are relative to the **total program
264
267
execution**. This is useful to help you keep perspective -- often as
@@ -270,8 +273,7 @@ are easily compared against one another.
270
273
That said, sometimes it's useful to get relative percentages, so `perf
271
274
focus` offers a `--relative` option. In this case, the percentages are
272
275
listed only for samples that match (vs all samples). So for example we
273
-
could find out get our percentages relative to the borrowck itself
274
-
like so:
276
+
could get our percentages relative to the borrowck itself like so:
0 commit comments