Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Rust should have a pleasant edit-compile-debug cycle #1
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.
@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.