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

The permutations iterator that I put into libstd (and was removed before Rust 1.0) was slow anyway. Happy it’s gone :smile:. The new impls in crate permutohedron are better.

1 Like

I was using a v1.9, but I’ve just updated the compiler to (64 Windows):
rustc 1.9.0-nightly (b678600ac 2016-03-29)

The compile-time, without optimizations, is now a bit higher, about 12.9 seconds :frowning:

Right, sorry! I forgot about this method, and I wasn’t able to find it again in the docs… Perhaps the Vec functions/algorithms could be grouped by purpose (searching, mutation, and so on) in the docs.

Beside that concat function useful for multiple slices to concat, I think I’d like to use an operator to concatenate one vector and a slice, like you do for strings:

fn main() {
    let s1 = String::from("Hello ");
    let s2 = "World";
    let s3 = s1 + s2;

I’m sure this was discussed a lot in past.

1 Like

Now with rustc 1.11.0-nightly (12238b984 2016-06-04) the compilation times are more reasonable:

-C opt-level=0 -Z no-trans: 0.62 seconds
-C opt-level=0 -C prefer-dynamic: 1.94 seconds
-C opt-level=3 -C target-cpu=native: 2.44 seconds

Now with -C opt-level=3 the Rust code compile time is just about twice the compilation time of the roughly equivalent Haskell code (1.11 seconds with GHC v. 7.10.2, -O3).


Now with rustc 1.11.0-nightly (ad7fe6521 2016-06-23):

-C opt-level=0 -Z no-trans: 0.48 seconds
-C opt-level=0 -C prefer-dynamic: 1.69 seconds
-C opt-level=3 -C target-cpu=native: 2.24 seconds

Now with rustc 1.12.0-nightly (0a3180baa 2016-08-03):

-C opt-level=0 -Z no-trans: 0.48 seconds
-C opt-level=0 -C prefer-dynamic: 1.93 seconds
-C opt-level=3 -C target-cpu=native: 2.40 seconds

The compilation times have recently increased (in other code I’ve seen even more increase).

Also note with -Zorbit=off:

-Zorbit=off -C opt-level=0 -C prefer-dynamic: 1.61 seconds
-Zorbit=off -C opt-level=3 -C target-cpu=native: 2.10 seconds

Thanks for keeping these performance changes bumped @leonardo. I strongly encourage you to file bugs every time you see a reproducible regression as well.

cc @eddyb @nikomatsakis some perf regressions here.

1 Like

The biggest compilation time regression I’ve seen in the last 3 days is for the whole pack of my Euler problems solutions, from about 42 seconds to about 61 seconds (the binary is also a bit bigger and the run-time is a little longer, but this is a small change). The code in that single module stresses the compiler a lot, I presume. I think it could be used in some kind of regression suite for Rust, but it’s a little large module… it contains the efficient solutions to the first 210 problems.

1 Like

That does sound like a good candidate for a compile-time perf suite cc @nrc.

Now with rustc 1.14.0-nightly (f09420685 2016-10-20):

-C opt-level=0 -Z no-trans: 0.26 seconds
-C opt-level=0 -C prefer-dynamic: 0.86 seconds
-C opt-level=3 -C target-cpu=native: 1.39 seconds

The compilation times have halved!? (It’s now a bit faster than the Haskell compiler, that takes about 1.4 seconds for the Haskell code with -O3, GHC version 8.0.1).

1 Like

Maybe it is partly thanks to this change by nnethercote, among many other incremental improvements lately

With rustc 1.14.0-nightly (cae6ab1c4 2016-11-05) the timings are about unchanged:

rustc -C opt-level=0 -Z no-trans 0.25 seconds
rustc -C opt-level=0 -C prefer-dynamic 0.84 seconds
rustc -C opt-level=3 -C target-cpu=native 1.38 seconds

But there’s a surprise for me:
rustc 1.41 seconds
rustc -O 1.83 seconds

Apparently -C target-cpu=native is making a lot of difference now, do you know why? I think in past it didn’t make much difference.

Edit: I’ve compiled some other programs, and -C target-cpu=native doesn’t change the compilation time much, so it’s not a general pattern.

The timings have changed in an interesting way:

rustc -C opt-level=0 -Z no-trans 0.22 seconds
rustc -C opt-level=0 -C prefer-dynamic 0.76 seconds
rustc -C opt-level=3 -C target-cpu=native 1.30 seconds
rustc 1.49 seconds
rustc -O 1.86 seconds

ghc test2.hs: 1.88
ghc -O3 test2.hs: 1.70

Something stranger has happened in the meantime (rustc 1.16.0-nightly (83c2d9523 2017-01-24):

rustc -C opt-level=0 -Z no-trans 0.48 seconds
rustc -C opt-level=0 -C prefer-dynamic 1.08 seconds
rustc -C opt-level=3 -C target-cpu=native 1.61 seconds
rustc 1.28 seconds
rustc -O 1.69 seconds

Ant the resulting binary sizes keep growing.

Using rustc 1.17.0-nightly (4be034e62 2017-02-27):

rustc -C opt-level=0 -Z no-trans 0.54 seconds
rustc -C opt-level=0 -C prefer-dynamic 1.13 seconds, 191_040 bytes
rustc -C opt-level=3 -C target-cpu=native 1.66 seconds, 1_097_582 bytes
rustc 1.33 seconds, 1_218_762 bytes
rustc -O 1.74 seconds, 1_097_582 bytes

The compilation time has grown up a bit. The binary sizes have kept slowly growing almost every day since months, and with the last rustup update (2017-02-27) then have had another increment.

1 Like

Yes, I’ve noticed a significant different between stable (1.15.1) and nightly. Enough to make me prefer stable!

rustc nightly-x86_64-pc-windows-gnu 1.17.0-nightly (cab4bff3d 2017-03-21):

rustc -C opt-level=0 -Z no-trans 0.18 seconds
rustc -C opt-level=0 -C prefer-dynamic 0.81 seconds, 194_394 bytes
rustc -C opt-level=3 -C target-cpu=native 1.32 seconds, 1_138_133 bytes
rustc 0.99 seconds, 1_261_386 bytes
rustc -O 1.41 seconds, 1_138_133 bytes

More generally, I think binary sizes have had a spike up, compilation times have decresed a little, run-times have decreased a bit.

Thanks for continuing to track this @leonardo.

rustc nightly-x86_64-pc-windows-gnu 1.18.0-nightly (7627e3d31 2017-04-16):

rustc -C opt-level=0 -Z no-trans 0.18 seconds
rustc -C opt-level=0 -C prefer-dynamic 0.79 seconds,191_709  bytes
rustc -C opt-level=3 -C target-cpu=native 1.35 seconds, 1_132_923 bytes
rustc 0.98 seconds, 1_250_669 bytes
rustc -O 1.43 seconds, 1_132_923 bytes

Binary sizes are a little smaller, compilation time is almost the same. In Nightly the run-time of the compiled code has decreased for some benchmarks since the precedent day.


rustc nightly-x86_64-pc-windows-gnu 1.18.0-nightly (252d3da8a 2017-04-22):

rustc -C opt-level=0 --emit=metadata 0.17 seconds
rustc -C opt-level=0 -C prefer-dynamic 0.70 seconds, 186_196 bytes
rustc -C opt-level=3 -C target-cpu=native 1.25 seconds, 1_099_576 bytes
rustc 0.89 seconds, 1_212_027 bytes
rustc -O 1.33 seconds, 1_099_576 bytes

Compilation time is “significantly” decreased (because of ), the binary sizes are a little smaller, and performance benchmarks of other binaries show a small decrease.


The new LLVM is a little slower on my programs, so now the compilation times are back to before pull 4146920. The binaries are a bit smaller, and their performance has shown a relevant increase!

(Some of the performance spots I’d like to see improvements on are u128 division that isn’t inlined, hashing, Bigint of num crate that are slower than Java bigints. Also Rust string don’t cache their hash value, this sometimes causes performance problems).