Make --release default (at least for dependencies)

[kud1ing]

Is there a reason why building (dependencies) with full optimization is an opt-in?

I can imagine it will lead to many "Rust is slow" complains, as in:

A: It's rather nice to work with, but it's a bit too slow for me to actually use.
B: If you are using Cargo, you need --release to get the full optimization.

http://www.reddit.com/r/rust/comments/2kp1di/presenting_rustimage_v01/clnihza

[huonw]

--release is significantly slower to build, and every other compiler I know of defaults to no-opt.

[kud1ing]

That's fine for compiler settings.

I would optimze package manager settings for package users and not package developers, because
packages are likely to have more package users than package developers.

[huonw]

The people running cargo build will be developers. Maybe you're just suggesting cargo build --release be the default for the dependencies themselves? (That is, cargo build will optimise any dependencies but build the current project unoptimised.)

In any case, I opened #785 about another way we can reduce this confusion.

[kud1ing]

Yes, i meant for dependencies. Sorry for not being clearer. I've adjusted the title.

[alexcrichton]

I personally much prefer "give me a result fast" than "give me a fast result" when developing. I feel it tends to lead to better first impressions especially. This would be an interesting option to turn on, however!

[tomaka]

Optimizing the dependencies would also mean removing their debug symbols, making debugging harder.

[kud1ing]

I have two assumptions:

• subjective performance of your own code is more valuable than upgrade performance of the dependencies. Once the Rust ecosystem has stabilized, how often will you upgrade your dependencies? Also "It's rather nice to work with, but it's a bit too slow for me to actually use." is probably one of the worst first impression a dependency can have.
• I think people will mostly debug their own code, not so much the code of their dependencies.

[kud1ing]

Another Cargo user tripped over this:

it is incredible slow to do this in Rust

http://www.reddit.com/r/rust/comments/2omtj1/state_of_io_in_rust/

[tanadeau]

I've created an issue in rust-lang/rfcs for a similar problem with direct rustc usage (rust-lang/rfcs#777). It would be nice to have a message when using non-release builds that optimizations are turned off so that beginners (especially from JIT'ed/interpreted languages) know that "fast code" isn't the purpose of the default build.

I think a message is probably enough. A change in default behavior is, I think, unnecessary especially given the compilation time differences.

[dotdash]

I agree with @kud1ing on this one. Having to endure slow code in the dependencies just because I want to debug my code is rather unfortunate. Just consider how much fun it would be if you also had to build LLVM without optimizations just because you want to an unoptimized build of rustc. For me, building your dependencies without optimizations is often a "last resort" for debugging, when I consider that the dependency itself might be broken.

[kornelski]

@tomaka Perhaps the default should be to optimize the dependencies and keep their symbols? Of course debug info won't be as accurate for an optimized dependency, but that's not as important as for one's own code.

Personally I don't need more than dependencies' function names in the stack trace, but having them run fast, even in my debug code, would be great. I often write non-performance-sensitive "glue" code around libraries doing heavy lifting, so optimized dependencies would be great for me.

[kud1ing]

Another "Rust is slow" story: http://www.reddit.com/r/rust/comments/2x6652/experiences_migrating_a_go_project_to_rust/

[tbu-]

@kud1ing Complaining about the status quo like this is not necessarily good – you can't see if the other option would raise similar problems with users about the even slower compilation speed.

[kud1ing]

@tbu-: To me this issue is a suggestion to fix a problem that people encounter.
I've added some experience reports, because i think it validates the assumption that this is a persisting problem for a wider audience.

Can you point out what you'd like to see improved?

[tbu-]

I want to say that if you introduce a new problem by fixing the "problem that people encounter", then you might generate a new "problem that people encounter".

It is known that this is a problem, however that does not mean that the other problem (longer compilation times) isn't a "problem that people encounter", you just don't see that yet, because it's not yet changed.

[kud1ing]

Well that's natural to me. First you identify a problem and agree that it's worthwhile to solve. Then you try a solution and see that the solution is correct or even worth it.

I think this proposal right now is between step 1 and 2.
I'd be interested in @alexcrichton current view on this. I don't think i could add much to this discussion to make my point. Close it if you like.

[tomaka]

Even if it's not made default, I'd appreciate if there was a way to compile the dependencies in release.

If I compile the program I'm currently writing in debug mode, it takes ~10 seconds to compile but has a loading screen of around ~20 seconds (loading data is done by dependencies). If I compile it in release mode, it takes ~30 seconds to compile but the loading screen is almost instant.

If dependencies were compiled in release mode and the program in debug mode, I would get the best of the two worlds: 10 seconds to compile and an almost-instant loading screen.

[kud1ing]

If you look at Haskell's cabal or Node's npm etc., you'll see that package managers are not only used by developers to build the software they are writing, but it's also a means for users of software to download, compile and install it.

People are used to commands like foo install bar. I don't want cargo to be the exception, where you get dog-slow software unless you keep remembering to always add a "--release".

[huonw]

The defaults for the hypothetical cargo install command are orthogonal to the defaults for the cargo build command. (I personally would expect most people to agree with cargo install defaulting to --release.)

[kud1ing]

I guess a default flag --release makes sense for all software someone just wants to use. It thus would apply to both whole software packages and library dependencies (install and build).

[steveklabnik]

No, it would be for `install`. If you're building yourself, then you need to understand what the build does.

[globin]

At least I definitely more often need shorter build times and easier "debugability" when building as 99% of the time I'm building while developing and relying on test and/or typecheck.

For install I agree that optimisations should be enabled by default. They are currently on my install branch.

[kud1ing]

If you're building yourself, then you need to understand what the build does.

I can't follow. When i am using third party libraries i almost never want to debug them, unless they are really buggy.

[steveklabnik]

(to be clear, my comment was just about a regular build, not dependencies. I'm not sure how I feel about their setting)

[kud1ing]

I think that one wants the dependencies optimized most of the time. I am not sure about one's own code. Longer build times are a downside. People publishing unoptimized benchmarks suck too.

[tanadeau]

I created #1309 a while ago to log the profile so that at least people can say the've been warned.

[alexcrichton]

@kud1ing

I'd be interested in @alexcrichton current view on this. I don't think i could add much to this discussion to make my point. Close it if you like.

I agree with your analysis here. This is a real problem, but I'm not sure that we've settled on quite the right solution just yet.

I think that the gist of #1309 that @tanadeau is proposing is quite promising, however.

---

@tomaka

Even if it's not made default, I'd appreciate if there was a way to compile the dependencies in release.

I very much agree! I have opened #1359 on this topic.

[lahwran]

I like the idea of cargo reminding me that I built something in debug mode and not fast mode, not just rustc reminding me. It would also be nice for cargo to point out to me that it puts release binaries elsewhere, because even knowing I needed --release to get fast code, my benchmarks were skewed because I was running the debug binary in target/projectname, not the release one in target/release/projectname. It was off by a factor of 10, and was enough slower that I did a major refactor for performance - which did end up doubling speed once optimizations were on, but that's 0.25 sec vs 0.13 sec, so w/e.

[alexcrichton]

@lahwran that's actually another separate issue as well!

#785

[luser]

--release is significantly slower to build, and every other compiler I know of defaults to no-opt.

@huonw : I submit that this is not a fair analogy. cargo is not a compiler, it is a build system. Many projects' build systems default to building with optimization by default (Firefox included) so that the resulting binaries are usable for their intended purpose, and require passing extra flags to get an unoptimized build (--disable-optimize for Firefox) or a build with extra assertions (--enable-debug for Firefox).

It's fine for rustc, which is a compiler, to default to building without optimization (like most other compilers), but the argument for cargo is not as straightforward.

[kud1ing]

Just for reference, people still trip over this: https://www.reddit.com/r/rust/comments/4tikmf/why_is_my_forth_virtual_machine_written_in_rust/

[kornelski]

FWIW, people also forget to add -O to gcc, so the fact that other compilers don't optimize by default may not be the best decision for them either.

[qm3ster]

I have a question about cargo install. Where is the --release profile that is used to install binaries to my system?
I am asking in order to make sure that my binaries are installed with lto = true

[alexcrichton]

@qm3ster ah currently unless you check the crate out manually and modify it you can't cargo install with LTO enabled unconditionally

[ehuss]

If you want to experiment with a nightly unstable feature, you can use config overrides. The easiest way is probably to use an environment variable like this:

CARGO_PROFILE_RELEASE_LTO=true cargo +nightly install NAME -Z config-profile

[qm3ster]

@ehuss Am I correct to understand that -Z config-profile is required for cargo to pay attention to CARGO_PROFILE_RELEASE_LTO=true being in the environment?

[ehuss]

Am I correct to understand that -Z config-profile is required for cargo to pay attention to CARGO_PROFILE_RELEASE_LTO=true being in the environment?

@qm3ster correct.

[dagit]

People are still getting hung up on this: https://www.reddit.com/r/rust/comments/g8tebx/rust_handling_fewer_requests_per_second_than_node/fopimx2/

[kornelski]

Yeah, this is a recurring problem. In user forums there are also people showing up from time to time asking why Rust is slow, and half of the time it's just the --release flag.

[kornelski]

Now cargo has build-override feature that could be used to build deps in release mode. But I'm not sure anymore whether that's the good default, because then users could wonder why the app is fast in general, except their own code is slow.

So maybe this should be fixed with clearer messaging. Perhaps one-time-only message to avoid annoying regular users.

Currently Cargo prints:

Finished dev [unoptimized + debuginfo] target(s) in 15.19s

which is perhaps too subtle. What if it was a bit more explicit:

Finished dev [unoptimized + debuginfo] target(s) in 15.19s
warning: unoptimized build is SLOW. Build with --release to make it fast.

[timmyjose]

I've read all the comments in here, but the main issue in my opinion is that --release must be made default because apart from absolute beginners, debugging is not the normal state, running fast optimised code is. And yes, I'm talking during development. If something goes wrong, then one may use --debug to switch to debug mode. That is why practically all other languages offer release mode equivalents as the default and the programmer has to explicitly opt into debug mode.

Right now, an alias works fine, but I strongly feel that this default should be in the compiler itself.

[epage]

"must" is a strong statement. There are a lot of different cases and they depend on the size of the program, the developer workflow, the tests, and how everything is broken down. When you start getting into large, pure-Rust applications, the test times and runtimes can push people to doing release builds. There are still a lot of people on the other side of things, like myself, where I spend most of my time in the edit-build-test cycle and want fast compile times. I notice the build times when I run my benchmarks and would appreciate any help with it (like #2234) to avoid those slow release builds.

Something missing from this discussion is handling of path dependencies. Generally they are developed with their dependents, so should be debug by default, rather than release? However, some large applications will be just a single workspace and you can still run into wanting them built in release mode. I'm having a hard time seeing one true answer for this so this falls back to what case you should optimize for. Personally, I would lean towards developer productivity of new and independent developers rather than the large applications.

[timmyjose]

personally, I would lean towards developer productivity of new and independent developers rather than the large applications.

That is the main argument being brought about in the comments here though albeit in support of release rather than debug. Most complaints from people new to Rust (from the linked threads) seem to be about Rust execution being slow rather than the edit cycle.