As we come down the home stretch for 2017, @michaelwoerister and others have been hard at work getting incremental compilation ready to ride the trains to stable. But we need your help to get it across the finish line!

Here’s how you can help:

Grab a project with poor compile times Do cargo +nightly build --release Do: rm -rf target , then

, then time cargo +nightly build --release Do: rm -rf target , then

, then CARGO_INCREMENTAL=1 time cargo +nightly build --release Do: touch lib.rs , then

, then CARGO_INCREMENTAL=1 time cargo +nightly build --release Do: A trivial change to a method body (like adding a no-op), then

CARGO_INCREMENTAL=1 time cargo +nightly build --release Post the project and numbers here!

We want to hear about the timings you see, in part so that we can beef up the benchmark suite with a much wider range of examples. In the next several weeks, we expect some major improvements to incremental to land (e.g., being able to skip typeck), and we’d like to track the improvements to these numbers as that happens.

Note: these timings are based on the release profile because, today, incremental doesn’t help much with debug. That will be changing in the very near future.

For compiler team members: beyond extra benchmarks, what improvements to http://perf.rust-lang.org/ would be most helpful to track performance in incremental mode? Is it enough to have an easy-to-get “view”, using today’s knobs but not having to set them yourself? Or is there a view of the data you want but can’t get with today’s perf?

For everyone: if you have more thoughts about what/how we should be measuring or presenting measurements, please speak up!