webrender_api incremental benchmark

[nikomatsakis]

@jrmuizel tells me that:

cd webrender/webrender_api && cargo check && touch color.rs && cargo check

takes 8s on the second cargo check, and it would be good to measure it as well.

As of this writing, the current HEAD on webrender is aa73c6a18.

[jrmuizel]

My measurements:

| Phase            | Time (ms)      | Queries        | Hits (%) |
| ---------------- | -------------- | -------------- | -------- |
| Parsing          | 27             |                |          |
| Expansion        | 4322           |                |          |
| TypeChecking     | 455            | 662121         | 99.47    |
| BorrowChecking   | 0              | 56933          | 100.00   |
| Codegen          | 681            | 25615          | 99.98    |
| Linking          | 87             | 5              | 60.00    |
| Other            | 1363           | 2503325        | 99.18    |

Optimization level: No
Incremental: on

[jrmuizel]

The 5692 lines of rust code in webrender_api expand to 85511 with cargo expand. Does it seem reasonable for this size increase to map 4 seconds of time?

[nikomatsakis]

I'm not sure if I'd say it's reasonable but it seems realistic perhaps. I'm not entirely sure on what data is being put into "Expansion", would need to drill a bit more into it.

[jrmuizel]

Just taking a quick look through it looks like the majority of the expansion is caused by serde

[nnethercote]

cd webrender/webrender_api && cargo check && touch color.rs && cargo check

Note to self: in rustc-perf parlance, this is a "CleanIncr" build of the webrender_api crate. The perf-config.json file just needs its cargo_toml entry to point to webrender_api/Cargo.toml.

[nnethercote]

I've done some profiling. There is room for some improvement, but I don't see much scope for drastic wins. E.g. with a bit of effort I can envisage a 10% improvement. rust-lang/rust#59476 is a first, small step.

[nnethercote]

rust-lang/rust#59507 is a bigger improvement, saving over 5%.

Profiling shows that the most obvious remaining source of inefficiency is libproc_macro's buffer for communicating between client and server. Buffer::write_all is called more than a million times, almost always for a single byte, mostly due to uleb128 encoding of integers. @eddyb said they would try to improve that code. I estimate this could save another 10%.

[nnethercote]

I opened a rust issue to track the rustc changes. We can probably close this. We could consider if we want to add this (or a similar expansion stress test) to the benchmark suite.