debug_assert and debug logging shouldn't be enabled by default in optimized builds

[thestinger]

At the moment, using debug assertions is discouraged because it will hurt performance. In practice, no one disables assertions so they are not used: debug_assert! only has 11 uses in the Rust repository. It would have many more if I didn't feel I had to delete all of the assertions I used during development to avoid a 5-20% performance hit by default.

It would make a lot more sense to enable them by default only in non-optimized builds where the performance hit will be dwarfed by other issues. It would be overridden by passing an explicit --cfg switch, and Rust's build system could just use the default. Rust developers could easily override this, but users and packagers wouldn't be given a slow / bloated build by default.

This would make it acceptable to use debug_assert! for bounds checks in the unchecked indexing methods on slices and the very valuable jemalloc debugging assertions could also be enabled by default in an unoptimized build. Using the debug variant of mutexes rather than faster deadlocking ones is another example. There are bots building and testing with no optimizations, so there would be better testing coverage.

[gamazeps]

On it :)

[bluss]

cargo build --release does the right thing, so it is already quite viable to use debug_assert! in the users' own packages.

[sfackler]

As @bluss noted, cargo already passes --cfg ndebug for release builds. The most straightforward fix here for rust itself would probably be to have --enable-optimize imply --disable-debug.

[thestinger]

I think rustc's behaviour should be consistent with the higher-level Cargo semantics, not just Rust's own build system.

[thestinger]

This will be the only major reason for #8859 after my latest heap pull request lands. Debug logging causes an enormous start-up time hit on Windows due to relocations from the global state.