This repository has been archived by the owner. It is now read-only.

Rust should have a pleasant edit-compile-debug cycle #1

Open
aturon opened this Issue Nov 7, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@aturon
Member

aturon commented Nov 7, 2016

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

@aturon aturon added the Vision label Nov 7, 2016

@SRGOM

This comment has been minimized.

Show comment
Hide comment
@SRGOM

SRGOM Feb 2, 2017

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.

SRGOM commented Feb 2, 2017

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.

@est31

This comment has been minimized.

Show comment
Hide comment
@est31

est31 Jul 8, 2017

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 commented Jul 8, 2017

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.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Jul 12, 2017

Member

@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.

Member

aturon commented Jul 12, 2017

@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.

@japaric japaric referenced this issue in japaric/svd2rust Jul 16, 2017

Closed

Remove #[inline(always)] #129

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.