Description
When using chained option iterators to build a collection, I found that compile times in release mode were longer than I expected. Originally this was reported on the Gotham gitter channel, and I wrote the following PR which has drastically improved the compile times on my machine:
To reproduce the issue in a more useful way, I've written the following which doesn't finish compiling in the rust playground:
https://play.rust-lang.org/?gist=de324d04c49e0702326210342a6e7d30&version=stable
This same code compiles on my machine in approximately 2 seconds (or 3.5 seconds with rustc -O), vs ~150ms for a simple "Hello, world!" style application.
Rightly or wrongly, I didn't expect the impact on compile times to be this drastic, though I feel that I've just hit an edge case and the easiest answer is to write better Rust code.
Compile time on Gotham's 0.2-maint branch, which didn't yet have the above PR merged:
(rustc CPU usage was sitting at 100% of a single core for the duration)
$ cargo build --release
Compiling gotham v0.2.1-dev
Finished release [optimized] target(s) in 1047.79 secs
Compile time on the branch used to submit the above PR:
$ cargo build --release
Compiling gotham v0.2.1-dev
Finished release [optimized] target(s) in 5.38 secs
On scanning the issue tracker, I found #22204 which may be the same problem, but I'm not entirely sure.
Meta
I tried this on my stable and nightly compilers, which both exhibited the same behaviour. The output above is from my nightly compiler.
$ rustc --version --verbose
rustc 1.26.0-nightly (482a913fb 2018-03-25)
binary: rustc
commit-hash: 482a913fb337855072a53c0d602cd19947f45285
commit-date: 2018-03-25
host: x86_64-apple-darwin
release: 1.26.0-nightly
LLVM version: 6.0
$ rustc +stable --version --verbose
rustc 1.24.0 (4d90ac38c 2018-02-12)
binary: rustc
commit-hash: 4d90ac38c0b61bb69470b61ea2cccea0df48d9e5
commit-date: 2018-02-12
host: x86_64-apple-darwin
release: 1.24.0
LLVM version: 4.0