On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar <jmuizel...@mozilla.com> wrote:
> As another piece of evidence in support opt-level=1 being the wrong > default, Glenn also got bitten profiling with the wrong options. > https://github.com/servo/webrender/issues/1817#issuecomment-340553613 It is "wrong" for the set of "people performing profiling." This set is different from "people compiling Gecko." Which is different from "people who actually need to compile Gecko." What I'm trying is the new default is "not wrong" for a large set of people who aren't "people performing profiling." My opinion is that this class of failure is a UX failure revolving around the question of "am I building the thing that should be used for X?" The build workflow does a horrible job of asking this critical question. The closest we have is `mach bootstrap` asking if you are building {Firefox, Fennec} {with, without} artifact builds. And we don't do a good job of transitioning between `mach bootstrap` or forcing people to run it at all. So we essentially have nothing forcing people to answer a question that has critical implications for their ability to adequately develop Firefox. I have ideas for solving this problem. But to do it in a way that results in fewer people falling through "my build configuration is sub-optimal and I didn't know it" cracks, we need to eliminate the concept of a "default build configuration" and require people to specify a build configuration (by creating a mozconfig file, etc). This is because the reality is that there is no single "default build configuration" that is ideal for everyone. There are more details and some discussion in bug 1410262. I'd rather we morph that bug as needed than discuss on this mailing list. I'm happy to discuss on this mailing list eventually: I just want it to be after we have general agreement on a concrete proposal. > > > On Thu, Oct 26, 2017 at 2:51 PM, 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? > > > > -Jeff > > > > 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
