Rust should have a pleasant edit-compile-debug cycle
aturon opened this issue · 3 comments
Overview
The edit-compile-debug cycle in Rust takes too long, and it's one of the complaints we hear most often from production users. We've laid down a good foundation with MIR (now turned on by default) and incremental compilation (which recently hit alpha). But we need to continue pushing hard to actually deliver the improvements. And to fully address the problem, the improvement needs to apply to large Rust projects, not just small or mid-sized benchmarks.
To get this done, we're also going to need further improvements to the performance monitoring infrastructure, including more benchmarks. Note, though, that the goal is stated qualitatively, and we need to be careful with what we measure to ensure we don't lose sight of that goal.
While the most obvious routes are direct improvements like incremental compilation, since the focus here is primarily on development (including debugging), another promising avenue is more usable debug builds. Production users often say "debug binaries are too slow to run, but release binaries are too slow to build". There may be a lot of room in the middle.
Depending on how far we want to take IDE support (see below), pushing incremental compilation up through the earliest stages of the compiler may also be important.
Projects
- Incremental compilation, which allows the compiler to do far less work when re-compiling.
- Trait system rewrite, a reworking of the trait system that may yield significant performance improvements.
I strongly believe Rust needs a REPL to play around with types (scala REPL prints the type of every expression) and getting a hang of things.
Compared to chalk or incr comp, adding the ability to optimize only dependencies (with debug info being kept) is a very low hanging fruit and very helpful IMO if you have to use release mode for your dependencies because otherwise it would be unbearably slow.
@est31 Yes, that may indeed be worth pursuing -- and if you're interested in working together on a design for it, I'd love to help!
The fly in the ointment, though, is that any code that uses generics won't straightforwardly benefit. To make that work, we'd have to track optimization profiles through monomorphization, which is a rather big project.
Nevertheless, it could be worth picking the low-hanging fruit here (of just changing the optimization level for monomorphic code in dependencies) and seeing how far it gets us.