@@ -37,6 +37,8 @@ They mostly consist of real-world crates.
37
37
- ** ripgrep-13.0.0** : A line-oriented search tool. A widely-used utility.
38
38
- ** serde-1.0.136** : A serialization/deserialization crate. Used by many other
39
39
Rust programs.
40
+ - ** serde_derive-1.0.136** : A proc-macro sub-crate used by ` serde ` . Used by
41
+ many other Rust programs. Stresses declarative macro expansion somewhat.
40
42
- ** stm32f4-0.14.0** : A crate that has many thousands of blanket impl blocks.
41
43
It uses cargo features to enable large portions of its structure and is
42
44
built with ` --features=stm32f410 ` to have faster benchmarking times.
@@ -96,8 +98,8 @@ compiler in interesting ways.
96
98
actix-web and other libraries with similarly nested type combinators.
97
99
- ** regression-31157** : A small program that caused a [ large performance
98
100
regression] ( https://github.com/rust-lang/rust/issues/31157 ) from the past.
99
- - ** token-stream-stress** : Constructs a long token stream much like the ` quote `
100
- crate does, which caused [ quadratic
101
+ - ** token-stream-stress** : A proc-macro crate. Constructs a long token stream
102
+ much like the ` quote ` crate does, which caused [ quadratic
101
103
behavior] ( https://github.com/rust-lang/rust/issues/65080 ) in the past.
102
104
- ** tt-muncher** : Calls a quadratic TT muncher macro (based on ` quote::quote! ` )
103
105
with a long input, which stresses macro expansion.
@@ -188,13 +190,8 @@ Rust code being written today.
188
190
applies correctly, e.g. `target/release/collector bench_local +nightly
189
191
--id Test --profiles=Check --scenarios=IncrPatched
190
192
--include=$NEW_BENCHMARK`
191
- - ` git grep ` for occurrences of the old benchmark name (e.g. in
192
- ` .github/workflows/ci.yml ` or ` ci/check-*.sh ` ) and see if anything similar
193
- needs doing for the new benchmark... usually not.
194
- - Add the new entry to ` collector/benchmarks/README.md ` . Don't remove the
195
- entry for the old benchmark yet.
196
- - Compare benchmarking time for the old and new versions of the benchmark.
197
- (It's useful to know if the new one is a lot slower than the old one.)
193
+ - Add the new entry to ` collector/benchmarks/README.md ` .
194
+ - Consider the benchmarking time for the benchmark.
198
195
- First, measure the entire compilation time with something like this, by
199
196
doing this within the benchmark directory is good:
200
197
```
@@ -230,9 +227,13 @@ Rust code being written today.
230
227
231
228
## Update a benchmark
232
229
233
- - Do this in two steps. First add the new version of the benchmark. Once the PR
234
- is merged, make sure it's running correctly. Second, remove the old version
235
- of the benchmark. Doing it in two steps ensures we have continuity of
236
- profiling coverage in the case where something goes wrong.
230
+ - Do this in two steps.
231
+ - First add the new version of the benchmark. Compare the benchmarking time
232
+ of the two versions to make sure nothing outrageous has happened. Once the
233
+ PR is merged, make sure it's running correctly.
234
+ - Second, remove the old version of the benchmark.
235
+ Doing it in two steps ensures we have continuity of profiling coverage in the
236
+ case where something goes wrong.
237
+ - Compare the benchmarking time of the two versions.
237
238
- When adding the new version, for `perf-config.json` and the `N-*.patch`
238
239
files, use the corresponding files for the old version as a starting point.
0 commit comments