Std library inclusion policy, and a data point of compilation times

Not yet. Currently discussing the problem on IRC...

Update: apparently the problem is not visible in the msvc and Linux64 targets. I've seen it on the gnu64 target. Is someone willing and able to test it on the gnu32 target?

https://github.com/rust-lang/rust/issues/44183

In my code since the 1.24.0-nightly 2017-12-15 I'm seeing about 20-22% increase of compilation times using --emit=metadata (and I am using less than 30 constants), and more than 5% performance decrease of the binary. And every day since (2017-12-16 and 2017-12-17) things are getting a little worse. Alarm! :slight_smile:

4 Likes

Ouch! That sounds pretty bad. Should post on this on the internals list perhaps?

First I'll try to better pinpoint where the problems are...

2 Likes

Sounds good :slight_smile:

I've opened a bug report, the whole deal took me more time than expected:

https://github.com/rust-lang/rust/issues/46897

4 Likes

In the bug report comments arielb1i is asking if someone is able & willing to reproduce the problem on other hosts.

(quick compliment: I admire your continued efforts to measure, detect, and pin-point these compiler slowdowns. It is non-trivial and valuable feedback. Thanks! :heart: )

6 Likes

The last Nightly (1.25.0 bacb5c58d 2018-01-26 x86_64-pc-windows-gnu) gives me 20% smaller stripped binaries, it's a significant improvement. The binaries are a bit slower, but not significantly so.

3 Likes

With the last Nightly (x86_64-pc-windows-gnu 9cb18a92a 2018-03-02) the compilation using --emit=metadata is twice slower.

1 Like

And it was mostly fixed in the successive Nightly.

1 Like

Probably this, which was fixed by reverting a bit that wasn't meant to be included

https://github.com/rust-lang/rust/issues/48660

1 Like

The last nightly compiles again (rustc x86_64-pc-windows-gnu 1.26.0-nightly, 521d91c6b 2018-03-14):

rustc -C opt-level=0 --emit=metadata test.rs: 0.22 seconds
rustc -C opt-level=0 -C prefer-dynamic test.rs: 1.92 seconds, 136_704 stripped bytes
rustc test.rs: 2.00 seconds, 805_888 stripped bytes
rustc -O test.rs: 2.34 seconds, 733_184 stripped bytes
rustc -C opt-level=3 -C target-cpu=native test.rs: 2.35 seconds, 735_232 stripped bytes
rustc -C opt-level=3 -C target-cpu=native -C panic=abort -Z mir-opt-level=3 -C lto test.rs: 4.10 seconds, 202_240 stripped bytes

But now the compiler is much slower (perhaps nearly un-usably slower for me). In other longer code of mine I am seeing 11X compilation times using "--emit=metadata", and 15X compilation times for optimized builds :frowning:

1 Like

@leonardo, that nightly is the first after the merge of the MIRI-based constant evaluator which caused some performance regressions. We are actively working on getting performance back to where it was. On a grand scale, we th regression has not been as severe as you are observing (see http://perf.rust-lang.org/). Would you mind providing a link to the programs you are testing?

1 Like

And now it's fixed, I am seeing (Nightly x86_64-pc-windows-gnu adf2135ad 2018-03-17) about 6% slowdown in the optimized compilation.

3 Likes

The compiler performance has changed:

rustc 1.28.0-nightly (a3085756e 2018-05-19) x86_64-pc-windows-gnu:

rustc -C opt-level=0 --emit=metadata test.rs: 0.23 seconds
rustc -C opt-level=0 -C prefer-dynamic test.rs: 0.49 seconds, 118_272 stripped bytes
rustc test.rs: 0.83 seconds, 818_688 stripped bytes
rustc -O test.rs: 1.08 seconds, 739_328 stripped bytes
rustc -C opt-level=3 -C target-cpu=native test.rs: 1.02 seconds, 739_840 stripped bytes
rustc -C opt-level=3 -C target-cpu=native -C panic=abort -Z mir-opt-level=3 -C lto test.rs: Issue #50411

The performance problems with "--emit=metadata" I saw months ago seems mostly solved now, perhaps thanks to https://github.com/rust-lang/rust/pull/50744 too.

Some time has passed, and there are some differences:

rustc 1.64.0-nightly (d68e7ebc3 2022-07-20) x86_64-pc-windows-gnu:

rustc -C opt-level=0 --emit=metadata test.rs: 0.23 seconds
rustc -C opt-level=0 -C prefer-dynamic test.rs: 0.65 seconds, 93_184 stripped bytes
rustc test.rs: 0.95 seconds, 1_071_104 stripped bytes
rustc -O test.rs: 1.22 seconds, 1_011_712 stripped bytes
rustc -C opt-level=3 -C target-cpu=native test.rs: 1.19 seconds, 1_011_712 stripped bytes
rustc -C opt-level=3 -C target-cpu=native -C panic=abort -Z mir-opt-level=3 -C lto test.rs: 5.84 seconds, 262_656 stripped bytes

Bumping really old topics like this isn't something you're supposed to do. It pings people who might still be subscribed, but might not be interested any more. It's why newly-created topics are set to automatically close after a few months.

Have you tried to get your test.rs benchmark merged into the rustc-perf benchmark suite? It provides nicer tooling to track these numbers over time than posting code blocks in Discourse, and it's run more often.

2 Likes

The converse is of course also true: I might be subscribed precisely because I want to be pinged.

The homepage of the forum is a never-ending stream of new posts, so I often skim it very briefly. The auto-close functionality had not helped here. In my opinion, it's valuable to be able to track old posts without having to be "lucky" and notice new posts.

2 Likes

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.