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

[db48x]

An interesting question!

Looking at https://github.com/Wilfred/remacs, I see that it takes ~1m20s to compile ~450k lines of C (and a tiny amount of Rust and a dozen Rust dependencies; tested by running time (make -j16 lib-src && cd src && make -j16 temacs)), and then ~30s to compile ~20k lines of Rust (plus a couple dozen Rust dependencies; tested by running time (cd rust-src && cargo build)).

Then it takes about 5 minutes to compile 1.5M lines of Emacs Lisp code. (Tested by running time make -j16 lisp)

Looks like the Rust compiler is a lot slower when measured in lines/second (but I didn't count the lines from the Rust dependencies, so the test needs refinement).

And then there's the test suite, but I'm not going to measure that.

Of course, In practice you're almost always doing a partial build; it usually takes less than 10 seconds to get the first error message if you're working on the Rust code, so it's not too bad. We wouldn't complain if it was faster, but it's not actually painful.

[jaroslaw-weber]

I have two short wasm scripts and for some reason it takes 17 minutes to build them with travis.
Here is a link to travis job:
https://travis-ci.org/jaroslaw-weber/cbt-diary

I use caching so I wonder what is wrong.

[saethlin]

Link to code: https://github.com/saethlin/slack-rs-api

Which workflow is slow: All of the above, but I'd really really please like cargo check to be much faster.

What performance I'm seeing: 11 seconds to run cargo check, once in a working loop, and 20 seconds for cargo test.

What performance I expect: Closer to 1 second for cargo check when working on a piece of leaf code, such as the definitions in src/mods/channels.rs.

[gwenn]

I am not sure it is related to rustc or lalrpop.
It used to build fine on Travis but not anymore.
https://travis-ci.org/gwenn/sqlpop/jobs/382770062

Could not compile `sqlpop`.
Caused by:
  process didn't exit successfully: `rustc --crate-name sqlpop src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=3862934bdca8eccc -C extra-filename=-3862934bdca8eccc --out-dir /home/travis/build/gwenn/sqlpop/target/debug/deps -C incremental=/home/travis/build/gwenn/sqlpop/target/debug/incremental -L dependency=/home/travis/build/gwenn/sqlpop/target/debug/deps --extern lalrpop_util=/home/travis/build/gwenn/sqlpop/target/debug/deps/liblalrpop_util-359298f5f78e02a6.rlib` (signal: 9, SIGKILL: kill)

The generated parser is huge...
I guess the process is killed because it takes too much memory.
And I cannot check on my old laptop.

[gnzlbg]

• Link to code: rust-lang/rust/librustc_trans/intrinsics.rs / librustc_check/intrinsics.rs/liballoc/alloc.rs`, ...
• Details of which workflow is slow ./x.py build --stage 1
• What performance are you seeing? A one line change (e.g. adding a comment) takes forever to rebuild (5-10 minutes? I am re-running right now), a huge amount of memory, and HDD space (~20-30Gb incremental compilation cache).
• What performance would you expect? A one line change compiles instantaneously.

---

• Link to code: rust-lang-nursery/stdsimd/coresimd/ppsv/api/*.rs
• Details of which workflow is slow: cd rust-lang-nursery/stdsimd/crates/coresimd && cargo test
• What performance are you seeing? A one line change (e.g. adding a comment) to one of the tests takes over one minute to build (maybe 2-3 minutes? re-running right now), a huge amount of memory, and HDD space.
• What performance would you expect? A one line change compiles instantaneously.

---

• Link to code: https://github.com/gnzlbg/slice_deque (~5kLOC crate)
• Details of which workflow is slow: cargo test
• What performance are you seeing? A one line change (e.g. adding a comment) to one of the tests takes too long to rebuild for such a tiny crate, but the worst part is that the incremental compilation cache for this crate takes 1.3 Gb of HDD space ! For 5kLOC ! I submit PRs to many tiny crates, and have like 100 Gbs of incremental compilation cache lying around, ~30 Gb of which are rustc...
• What performance would you expect? A one line change compiles instantaneously, the incremental compilation cache takes a "reasonable" amount of HDD space (I don't know, 10Mb? 100Mb seems high for 5kLOC, 1Gb is nuts).

---

• Link to code: https://github.com/fitzgen/mach (~5kLOC crate, C library wrapper)
• Details of which workflow is slow: cargo test
• What performance are you seeing? The incremental compilation cache for this crate takes > 1G Gb of HDD space ! For a dumb wrapper over a C library!
• What performance would you expect? A one line change compiles instantaneously, the incremental compilation cache takes a "reasonable" amount of HDD space (I don't know, 10Mb?)

---

So in summary, the incremental compilation caches for tiny crates are just really really big. I'd expect most of the people checking this out to be working on the Rust compiler. Is there a file in the compiler somewhere, where a one line change followed by a ./x.py build --stage 1 builds instantaneously (< 10s)? If not that's probably an as good place as any other to start, and you'll be the one benefiting from the improvements.

[mitchmindtree]

• Code: nannou
• Slow workflow: The initial cargo build --release takes 5 - 20 minutes depending on the laptop. cargo build is not much faster, but is unusable for realtime graphics and audio so is not an option anyway.
• Performance: Very slow, but this is expected due to the fact that all dependencies are being built from scratch. The problem is that we plan to do workshops where we'd like to introduce students to coding in a creative fashion (ala Processing sketches), however this initial build time massively eats into the lesson duration. It would be great if cargo provided some way of using a pre-built binary. Alternatively, it would be very useful when creating new "sketch"es if cargo could re-use dependencies that have already been built for other projects. The 20 minute initial build time on my friend's old macbook air is easily long enough for the moment of inspiration to pass by the time the build is ready for iterative sketching.

I should also mention that the stable, non-incremental re-building of the project is also extremely slow, but this seems seems to be reduced greatly when using nightly with incremental building enabled (~5secs as opposed to a 30secs-1min), so it seems like a fix for this is already in the pipeline.

[frankmcsherry]

Generally speaking timely and differential dataflow are slow to build. This seems to be mostly "in LLVM", but it is still a bit surprising as while there are a great many generics lying around (and likely massive monomorphisation), their use feels like it should be mostly plug and play. E.g. "we start with a data type of String, now it is a usize, now a (usize, usize)" which turns in to "we will re-codegen much of the system for each of these types even though by in large what we needed to know was just ::mem::size_of::<T>().

Here are some repo links; cargo test should go relatively slowly. @nikomatsakis and friends can also comment on the build times of the differential dataflow implementations of Polonius.

https://github.com/frankmcsherry/timely-dataflow
https://github.com/frankmcsherry/differential-dataflow

A concrete very slow to build repo is

https://github.com/frankmcsherry/differential-dataflow/tree/master/tpchlike

which usually takes about 20mins or so in release mode, again despite appearing relatively uncomplex (though certainly under the covers being wildly complicated, for reasons that aren't clear).

I wouldn't be surprised to learn that these programs take a while to compile because they are written in a complicated way, and perhaps one thing that would be helpful is advice on "performance debugging compilation": not making the compiler magically faster (obvs great), but explaining what makes the process slow and what idioms could avoid that (e.g. use boxing wherever you can afford it; generics seem smart, but are really expensive).

[michaelwoerister]

@gnzlbg, I just tried https://github.com/gnzlbg/slice_deque and I can reproduce your numbers. My incremental cache after cargo test is 34.6 MB. There must be a (system-specific?) bug at work here. Would you mind opening an issue about that so we can investigate further?

[gnzlbg]

@michaelwoerister thanks for looking into this, I will open an issue and CC you there

[alex]

https://travis-ci.org/alex/linux-kernel-module-rust/builds/380900065#L483

Command that is slow is cargo install cargo-update, which takes more than 5 minutes to run in a Travis environment. I'm not sure what a realistic target for improvement is, but if it was under 2 minutes that'd swell (albeit an extreme improvement)!

[aturon]

@mitsuhiko

I pinned down a version of sentry-cli that I can test across compiler versions, and here's what I'm seeing locally. (The workflows here are for just the "root" crate, after all dependencies have been processed already; clear_cache refers to the incremental compilation cache; times are in seconds)

Workflow { subcommand: "check", clear_cache: true }
crate,1.18.0,1.19.0,1.20.0,1.21.0,1.22.0,1.23.0,1.24.0,1.25.0,1.26.0,beta,
sentry-cli,6.0,5.5,6.6,6.1,6.1,6.0,7.7,8.6,7.7,8.5,

Workflow { subcommand: "check", clear_cache: false }
crate,1.18.0,1.19.0,1.20.0,1.21.0,1.22.0,1.23.0,1.24.0,1.25.0,1.26.0,beta,
sentry-cli,7.2,6.6,6.5,6.6,5.9,6.3,4.6,4.9,3.8,3.0,

Workflow { subcommand: "build", clear_cache: true }
crate,1.18.0,1.19.0,1.20.0,1.21.0,1.22.0,1.23.0,1.24.0,1.25.0,1.26.0,beta,
sentry-cli,21.7,22.2,23.6,23.3,-,21.6,20.0,18.2,19.0,16.7,

Workflow { subcommand: "build", clear_cache: false }
crate,1.18.0,1.19.0,1.20.0,1.21.0,1.22.0,1.23.0,1.24.0,1.25.0,1.26.0,beta,
sentry-cli,12.9,21.2,24.4,24.6,-,22.8,10.5,9.8,9.1,7.4,

[ordian]

• Link to code: https://github.com/paritytech/parity

Files	Lines	Blank	Comment	Code
856	205k	29k	31k	145k

• Which workflow is slow: All of the above. Especially cargo build when switching between commits (git bisect or git pull).
• What performance are you seeing?:

On a laptop with i7-3520m, rust stable 1.26 cargo build after cargo clean takes 20 minutes.
After touch ethcore/src/snapshot/mod.rs, cargo build takes 4 minutes!

(after git checkout <commit>, cargo build a few times)

size	parity/target/debug/
14.963G/	incremental/
12.420G/	deps/
3.871G/	build/

(one run)
Finished dev [unoptimized + debuginfo] target(s) in 1515.71 secs

• What would you expect?: Something less painful than this.

[jonhoo]

Link to code: https://github.com/mit-pdos/distributary (@ 1b518a5e83658f13dc5624e3780ca317c8fb7360)

Both build from scratch and rebuild after changes is generally somewhat slow (though it has been getting a lot better!). The issues are particularly noteworthy when you have few cores available. On my current 12HT AMD 2600X (so quite beefy!), things aren't too bad:

$ cargo clean
$ cargo check --all --all-targets
    Finished dev [unoptimized + debuginfo] target(s) in 1m 46s
$ touch basics/src/lib.rs
$ cargo check --all --all-targets
    Finished dev [unoptimized + debuginfo] target(s) in 10.15s
$ cargo b --release
    Finished release [optimized + debuginfo] target(s) in 3m 43s

Note that this is with the environment variables from rust-rocksdb/rust-rocksdb#166 set so that rocksdb isn't also compiled.

I'd like to echo @ordian's comments above that things get fairly frustrating when you switch between branches and recompile, or even if you make, say, changes to unit tests, and that causes the whole crate to be recompiled. Ideally I'd like to see turnaround of sub-10s when I make minor edits (add/rm println!, change test slightly, etc.) to any file in the above crate and then re-run cargo test.

[ipetkov]

I've got a project which has a bunch of generic future adapters which have lots and lots of bounds in order to keep things as decoupled as possible. There is also a few top level futures which unify all the adapaters in the crate, and checking/building that code slows things down 3-4x for cargo build and 20x for cargo check.

I had to specifically put that code behind a feature flag so I can disable it to keep my development sanity and let the CI build the whole thing. (My understanding is that this is due to rustc rechecking generic bounds over and over again without caching results, so looking forward to chalk improving this!)

Link to project: https://github.com/ipetkov/conch-runtime
Link to the top level futures I mentioned: https://github.com/ipetkov/conch-runtime/blob/56b3ccf252cdbb439e7c91f482b2c58fc31db8c3/src/spawn/ast_impl/top_level_impl.rs

# All examples with warmed up deps
$ touch src/lib.rs
$ cargo check --no-default-features --features 'conch-parser'
    Checking conch-runtime v0.1.4 (file:///Users/ivan/Desktop/shell_stuff/conch-runtime)
    Finished dev [unoptimized + debuginfo] target(s) in 2.45s
$ touch src/lib.rs 
$ cargo check
    Checking conch-runtime v0.1.4 (file:///Users/ivan/Desktop/shell_stuff/conch-runtime)
    Finished dev [unoptimized + debuginfo] target(s) in 40.92s
$ touch src/lib.rs 
$ cargo build --no-default-features --features 'conch-parser'
   Compiling conch-runtime v0.1.4 (file:///Users/ivan/Desktop/shell_stuff/conch-runtime)
    Finished dev [unoptimized + debuginfo] target(s) in 12.06s
$ touch src/lib.rs 
$ cargo build
   Compiling conch-runtime v0.1.4 (file:///Users/ivan/Desktop/shell_stuff/conch-runtime)
    Finished dev [unoptimized + debuginfo] target(s) in 47.29s

EDIT: Forgot to mention: I'd expect more of a linearish build time increase with more and more complex generic types rather than a the current blow up

---

Another semi-related topic: I really with that cargo/rustc could tell if I've changed #[cfg(test)] code and not recompile the entire crate if it doesn't need to. The idiomatic way to write unit tests is to stick them in the module they are testing, but with the slow compile times I've mentioned above this became so unbearable, that I resorted to writing integration-style tests for all my public APIs. That way, cargo can (slowly) build the crate once, and then I can hack on tests with a very quick rebuild-only-test-and-run cycle.

Worth noting I started doing this way before incremental compilation became stable, so I haven't checked if this would still be a problem because I have way too many tests to port back to the idiomatic unit testing way!

[wahn]

• Link to code: https://github.com/wahn/rs_pbrt (just a big junk of code ~ 40.9K lines of Rust code)
• I'm not sure I'd expect faster compilation times (C++ is pretty slow too), but I wish for compile times
  like this:
  https://www.youtube.com/watch?v=De0Am_QcZiQ&feature=youtu.be
  (fastforward to 15:16 to see complexity of game or 21:50 for compile times)

[therealprof]

Installing any binary with cargo install is really slow even on my somewhat beefy MBP 2017 with Core i7:

# cargo install --force cargo-bloat
    Updating registry `https://github.com/rust-lang/crates.io-index`
 Downloading cargo-bloat v0.5.0
  Installing cargo-bloat v0.5.0
...
    Finished release [optimized] target(s) in 2m 56s

Consecutive builds are no faster. And that tool is <1kLoC with 11 dependencies. On a fast machine like this I would expect the first build to be way below 1 minute and rebuilds without further changes instantaneous.

The same applies to pretty much all crates which can be installed using cargo install though clippy and exa are surprisingly quick to compile nowadays with just a bit over a minute.

[nieksand]

A case of crazy long compile times.

For a real, one-off program I wrote for work, I used Python to generate HashMap insert lines for about 4000 entries.

Here is a simplified example:
https://gist.github.com/nieksand/ff3f6ac228ec233ab5bc7865e9827907

debug build: 2.8 seconds
release build: >40 minutes. (I killed the build)

If you hold on to just the first 500 inserts or so... things are bit more manageable for debugging:

debug build: 0.4 sec
release: 10 sec

If you peek at perf top while it's running, the runtime is dominated by:

  92,36%  librustc_codegen_llvm-llvm.so    [.] llvm::DeferredDominance::applyUpdate
   3,41%  librustc_codegen_llvm-llvm.so    [.] llvm::DeferredDominance::applyUpdates

[gnzlbg]

stdsimd cannot implement some intrinsics because compile-times explode with increasing numbers of arms in match statements:

• Up to 256 arms compile-times seem to remain reasonable [*]: https://github.com/rust-lang-nursery/stdsimd/blob/master/coresimd/x86/macros.rs#L3

• Adding a single match statement with 4096 arms to stdsimd increases the total compilation time of the crate by a factor of ~3x: [tbm] fix bextri stdarch#190 This was deemed unacceptable, therefore core and std do not expose intrinsics taking 16-bit immediate mode arguments.

[*] By reasonable I mean that adding a new match statement with 256 arms to the library barely changes the compile-time of the library.