Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make release builds the default #17496

Closed
wants to merge 1 commit into from
Closed

make release builds the default #17496

wants to merge 1 commit into from

Conversation

thestinger
Copy link
Contributor

This cuts the compilation time for a trivial Rust program by 15-20% on
Windows due to a massive improvement in rustc start-up time. The debug
logging has a very high cost because it makes extensive use of mutable
global variables and those result in expensive relocations.

Creating debug builds by default discourages the usage of debug
assertions. The few debug assertions not removed before landing a pull
request are a significant performance problem for types like RefCell.

The defaults should cater to users or packagers building Rust rather
than compiler developers. A compiler developer can be expected to
override a default flag, but the same cannot be said of someone who
lacks the same in-depth knowledge of the project.

Even someone working on the standard libraries is not going to want to
pay the high cost for debug logging. Many people who contribute to the
compiler don't use the feature either, because a debugger tends to work
a lot better than inconsistent / bit-rotted logging code.

@thestinger
Copy link
Contributor Author

cc #8859

@thestinger thestinger added the I-slow Issue: Problems and improvements with respect to performance of generated code. label Sep 24, 2014
@alexcrichton
Copy link
Member

This has implications on, for example, the nightly distributions. An ICE in the compiler is still quite a frequent occurrence, and it's very handy to request more information via RUST_LOG for debug info. It may be the case that we want debug! to stick around for the near future, but remove it before 1.0.

I'd probably be comfortable at this point compiling the standard library with --cfg ndebug, but I would also want to ensure that all our automation continued to build test suites with debug assertions.

@brson
Copy link
Contributor

brson commented Sep 29, 2014

We've made this change (or similar) in the past and then unmade it for the reasons @alexcrichton states.

@brson
Copy link
Contributor

brson commented Sep 29, 2014

Besides startup time on windows are there other performance improvements?

@nrc nrc self-assigned this Sep 30, 2014
@nrc
Copy link
Member

nrc commented Sep 30, 2014

We should do this, however, we should make it easy for developers to get the old behaviour. This is a similar situation to parallel builds where the optimal settings for release vs development are very different. I propose #17665.

This cuts the compilation time for a trivial Rust program by 15-20% on
Windows due to a massive improvement in `rustc` start-up time. The debug
logging has a very high cost because it makes extensive use of mutable
global variables and those result in expensive relocations. It also
makes jemalloc debug assertions / logging tied to the same flag as ones
in the standard library or compiler.

Enabling debug assertions by default discourages their use, because
normal builds will be paying a cost for each one. The few debug
assertions not removed before landing a pull request are a significant
performance problem for types like `RefCell`.

The defaults should cater to users or packagers building Rust rather
than compiler developers. A compiler developer can be expected to
override a default flag, but the same cannot be said of someone who
lacks the same in-depth knowledge of the project.

Even someone working on the standard libraries is not going to want to
pay the high cost for debug logging. Many people who contribute to the
compiler don't use the feature either, because a debugger tends to work
a lot better than inconsistent / bit-rotted logging code.
@alexcrichton
Copy link
Member

@thestinger, would you be ok working with @nick29581 to implement what we ended up concluding was the route we wanted to go in? It's a little more involved than just flipping the defaults, but @nick29581 knows the details.

@nrc
Copy link
Member

nrc commented Oct 8, 2014

That is #17665, btw

@thestinger thestinger closed this Oct 22, 2014
@thestinger thestinger deleted the release branch October 22, 2014 16:34
lnicola pushed a commit to lnicola/rust that referenced this pull request Jul 11, 2024
minor: Bump `actions/download-artifact` and `upload-artifact`

These will stop working in a couple of days. I think we could still use them in a more efficient way, but more tweaking is needed for that.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
I-slow Issue: Problems and improvements with respect to performance of generated code.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants