Gather slow workflows from stakeholders

[aturon]

Have you ever complained that rustc is slow? We want to know more!

Please leave comments here with the following details:

• Link to code
• Details of which workflow is slow (cargo check, cargo build, cargo test, rebuild after changes, etc)
• What performance are you seeing?
• What performance would you expect?

These details will help us discover new problem areas, and potentially feed the benchmark suite.

[sgrif]

• Link to code: https://github.com/rust-lang/crates.io
• which workflow is slow: All of the above. Rebuild after changes is probably the mots pressing. touch src/lib.rs && cargo build and touch src/lib.rs && cargo build --tests are two big ones.
• What performance are you seeing?: cargo build is 20 seconds, cargo build --tests is ~30 seconds
• What would you expect?: Something well under 10 seconds. The code base isn't terribly large.

[mitsuhiko]

Most of our projects are quite painful to develop. The most painful ones are sentry-cli and sentry-semaphore (both are applications).

What's slow is mostly cargo build after doing small changes. In sentry-cli for instance it takes on my dual core macbook pro 2015 around 15 seconds on even the smallest changes (with incremental compilation). Compiling the entire project from scratch takes many minutes. cargo check takes 5 seconds even with just touching. cargo build takes without any changes around 30 seconds when just touching a file (touch src/commands/mod.rs is the one I just tried).

Semaphore is similar but actually takes significantly longer, something I have seen happen on other actix-web projects as well.

I would expect <5 seconds for small incremental changes on build and almost instant on cargo check.

I'm happy to assist you in any way you want with this as iteration times are the number one issue we have right now.

[Andy-Bell]

Only real issue I have seen with this may not be directly rustc/cargo core’s problem, but thought I would log here in case.

When targeting emscripten, using the recommended setup for wasm compilation linked to from the yew readme, I was seeing very long initial build times on the example yew projects, much larger than I would expect for a project of that size.

Link to example projects at the version we were testing with: https://github.com/DenisKolodin/yew/tree/c48a15488b404ee5cc7680037cff1f3642690255/examples

(OSX latest version, rust nightly from ~2 weeks ago - will confirm when on work machine tomorrow, using command cargo web start https://github.com/koute/cargo-web)

[yoshuawuyts]

I think testing actix-web compile performance might be a fun one. Probably a hello-world or something would do.

• Which workflow is slow? Cargo build. Initial compilation takes a rather long time.
• What performance are you seeing? Well over a minute of compiling on a rather beefy laptop.
• What performance are you expecting? Under ~30 seconds. The compilation time is probably proportional to the amount of code compiled - but it still feels surprising if you're just trying to build an HTTP server.

I feel web stuff is a common starting point for folks, so optimizing that might help people have a nicer initial experience! 😁

[penguin42]

Well there's my old rust-lang/rust#42596 that I think is still valid; I've not let it go the whole way, but on 1.26 it still got to 5G in a few seconds and I'd originally seen it hit 75G. Optimising my compile-time mandelbrot is probably not worth it given how weird it is, but it did take 20G of RAM if anyone fancies a challenge ( http://www.treblig.org/daveG/rust-mand.html )

[trishume]

On my laptop syntect with rustc 1.27.0-nightly (ac3c2288f 2018-04-18), about a 4500 line project, all "incremental" builds are where I do a clean build and then I change a constant number in a function and rebuild:

Edit: The first time I ran these tests a dumb bug in a different program was pegging 2 of my 4 cores. I've edited in the new results, but the old results may be representative of a 2 core laptop. I'm much more satisfied with the new results. Although I'm still disappointed at the duplicate error messages and the 2x overhead of building twice for no apparent reason. I don't confess to understand the reason but it seems like fixing it might be easier than finding other 2x perf wins.

• Takes 2.5s 1.2s for an incremental cargo check, according to time passes 700ms 300ms of this is in macro expansion. This is slower than I think a check build should take on a project this small.
• Takes 5s 2s for an incremental cargo build
• An incremental cargo test says the build takes 15.0s 5s. This is the worst one. I think all my code is being built at least twice as evidenced by duplicate error messages (also annoying), I think this is the same issue as cargo test compiles twice cargo#851 and has been happening I think since I first added doctests.

These incremental results on a recent compiler are much better than they used to be before incremental compilation and all the recent fixes, so kudos for that.

[aravindhsampath]

I just did this today. A hello world example of Actix-web takes 172 seconds on a Core i7 MacBook Pro with 16G of memory.
Link to code : https://github.com/actix/examples/tree/master/hello-world
Workflow: Build - takes 2+ minutes.
Expect: < 20 s
time cargo build --release
Finished release [optimized] target(s) in 171.27 secs
Rebuild after change takes 11.7 seconds.

Rust version: 1.26.0

[hammerandtongs]

I hope this is on point with your request -

cargo build makes my entire laptop slow (ubuntu).

I find adding "ionice -c3 cargo build" leaves my laptop responsive with little to no impact on the build time. The other benefit is that I have lower blood pressure during the sometimes long build.

I would love a feature added to cargo to put all builds at this priority vs having to wrap this command.

[richard-uk1]

winapi is known to be very slow on build - think it might be a combination of lots of files/Windows defender though.

[Evrey]

Link to Code

Pick any popular crate with tons of popular dependencies, such as actix-web. Make a clean initial build or re-build after a big cargo update.

Details of which workflow is small

Initial builds and builds after cargo update take up to a thousand years, depending on the size of your dependency chain. This is especially bad for starting a new project or just prototyping.

What performance are you seeing?

• Syncing the crates.io index takes ages.
• Building debug/test artifacts of all the dependencies takes forever.
• Compiling the project crate itself is - for my taste and use cases - pretty fast. Especially as soon as incremental builds are done.

What performance would you expect?

1. Start a new project / prototype.
2. Select a lot of the same deps I almost always or at least often use, such as serde or quickcheck.
3. Type a few 100 LoC.
4. cargo test
5. Wait a few seconds until the test results show up and then immediately resume the work flow. (Depending on the deps, this takes minutes.)

How do you propose we might solve that problem?

A first step might be to cache debug and test build artifacts globally in e.g. ~/.cargo/registry/target/. I have a lot of common deps, using almost always the same set of feature flags, which themselves have the always the same deps. So... basically [workspace] for dependencies. Careful not to make disk space explode, though. Perhaps drop build artifacts of older crate versions if newer one are created.

A second step would be to have a build server for the most common targets on crates.io, such as x86_64-pc-windows-msvc/-gnu, x86_64-unknown-linux-gnu, and whatever-macos-is. Push a new version to crates.io, and it compiles and caches cargo build and cargo test artifacts, perhaps for the default feature sets only. As an opt-in or opt-out, those cached build artifacts are downloaded alongside .crate files.

[sstangl]

Project is http://github.com/sstangl/openpowerlifting. It's primarily a data project. The Rust code is under the server/ directory. It implements a small (~5k lines) Rocket-based webserver that processes and serves the data.

The data is generated as CSV files, which we load into the server at startup using the csv crate. This takes around 40 seconds in debug mode, but is basically instant in release mode, so in practice we always build with --release. Tests need to load this CSV data multiple times, and so testing is done with cargo test --release.

On my laptop (i7, 8GB RAM), cargo build --release outputs Finished release [optimized] target(s) in 4m 22s. That is long but not terrible.

If I touch server/src/opldb/mod.rs and then execute cargo build --release again, that outputs Finished release [optimized] target(s) in 40.46s. That's a bit much -- it's painful to wait a minute every time I want to test a change.

Really, I want a way to specify that the csv crate should always be in release mode, even in debug builds.

We test our project using TravisCI, which generously provides free CI for F/OSS projects. On their infrastructure (https://travis-ci.org/sstangl/openpowerlifting), a single build takes about 13 minutes, about 10 minutes of which are building the server. That's a long while for feedback on a small project!

[sgrif]

I completely forgot the big daddy of perf issues I have...

• Link to code: https://github.com/diesel-rs/diesel (with the 128-column-tables feature enabled)
• Which workflow is slow: cd diesel && cargo build --features 128-column-tables
• What performance are you seeing?: Long enough to get in the car, drive to starbucks, drink my coffee, come back, see that it's not finished, do some laundry, walk the dog, and then see it's done.
• What performance would you expect?: Not that... At minimum,<1 coffee compile times. Preferably much less.

[mkeeter]

From the other end of the spectrum: I built a tiny livecoding system that compiles to a dylib whever anything changes, and the 900-line code base takes ~3 seconds to compile (calling cargo build --lib). I'd expect it to be < 1 second, from experience with C codebases of similar sizes.

The code is here, quite amateurish, and probably won't work on non-Macs because of the live-reloading tricks.

[NatTuck]

$ cargo new hello --bin
$ cd hello/
$ time cargo run
   Compiling hello v0.1.0 (file:///home/nat/Code/hello)
    Finished dev [unoptimized + debuginfo] target(s) in 0.44 secs
     Running `target/debug/hello`
Hello, world!

real    0m0.685s
user    0m0.461s
sys     0m0.144s

With C / gcc:

$ cat hello.c 
#include <stdio.h>

int main(int argc, char* argv[])
{
        printf("Hello from C\n");
        return 0;
}
$ time bash -c '(gcc -o chello hello.c && ./chello)'
Hello from C

real    0m0.110s
user    0m0.038s
sys     0m0.015s

With a fast language implementation:

$ cat hello.pl 
#!/usr/bin/perl
use 5.20.0;

say "Hello from Perl";
$ time perl hello.pl
Hello from Perl

real    0m0.008s
user    0m0.003s
sys     0m0.000s

[eminence]

What performance are you seeing?: Long enough to get in the car, drive to starbucks, drink my coffee, come back, see that it's not finished, do some laundry, walk the dog, and then see it's done.

for those non-dog owners out there (like me), this ends up being about 160 seconds for the entire dependency tree