On Thu, Oct 26, 2017 at 11:51 AM, Jeff Muizelaar <jmuizel...@mozilla.com> wrote:
> FWIW, WebRender becomes unusable opt-level=1. It also looks like style > performance takes quite a hit as well which means that our default > developer builds become unusable for performance work. I worry that > people will forget this and end up rediscovering only when they look > at profiles (as mstange just did). What's the use case for a > --enable-optimize, opt-level=1 build? > Yes, this was a painful trade-off. I acknowledge we still may not have the proper set of defaults or tweakable options in play. Currently, --enable-optimize is the default and it is tied to both C/C++ and Rust (Rust inherited the option). Would it help if we had a separate --enable-optimize-rust (or similar) option to control Rust optimizations so we have separate knobs? If we did that, --disable-optimize-rust could be opt-level 0 or 1 and --enable-optimize-rust could be opt-level=2. The local defaults would probably be --enable-optimize/--disable-optimize-rust (mirroring today). I'm not sure if it is possible, but per-crate optimization levels might help. Although, the data shows that the style crate is one of the slowest to compile. And, this crate's optimization is also apparently very important for accurate performance testing. That's a really unfortunate conflict to have and it would be terrific if we could make the style crate compile faster so this conflict goes away. I've filed bug 1412077 to track improvements here. > > On Wed, Oct 25, 2017 at 1:34 PM, Gregory Szorc <g...@mozilla.com> wrote: > > Compiling Rust code with optimizations is significantly slower than > > compiling without optimizations. As was measured in bug 1411081, the > > difference between rustc's -Copt-level 1 and 2 on an i7-6700K (4+4 cores) > > for a recent revision of mozilla-central was 325s/802s wall/CPU versus > > 625s/1282s. This made Rust compilation during Firefox builds stand out > as a > > long pole and significantly slowed down builds. > > > > Because we couldn't justify the benefits of level 2 for the build time > > overhead it added, we've changed the build system default so Rust is > > compiled with -Copt-level=1 (instead of 2). > > > > Adding --enable-release to your mozconfig (the configuration for builds > we > > ship to users) enables -Copt-level=2. (i.e. we didn't change optimization > > settings for builds we ship to users.) > > > > Adding --disable-optimize sets to -Copt-level=0. (This behavior is > > unchanged.) > > > > If you want explicit control over -Copt-level, you can `export > > RUSTC_OPT_LEVEL=<value>` in your mozconfig and that value will always be > > used. --enable-release implies a number of other changes. So if you just > > want to restore the old build system behavior, set this variable in your > > mozconfig. > > > > Also, due to ongoing work around Rust integration in the build system, it > > is dangerous to rely on manual `cargo` invocations to compile Rust > because > > bypassing the build system (not using `mach build`) may not use the same > > set of RUSTFLAGS that direct `cargo` invocations do. Things were mostly > in > > sync before. But this change and anticipated future changes will cause > more > > drift. If you want the correct behavior, use `mach`. > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
