On Tue, Oct 31, 2017 at 12:21:42PM -0700, Gregory Szorc wrote:
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."
I'll second this. For months I've had Servo and WebRender disabled in
most of my builds because they made my compiles so much slower. I tried
re-enabling them a few weeks ago when I got a new workstation, but gave
up after most of the compile finished in 7 minutes, and then cargo spent
another 8 minutes compiling on a single core. I tried some hacks to bump
the codegen-units setting, but it was heinously difficult, and didn't
help enough, so I gave up.
I suspect I'm not in the minority here.
After this change, I'm considering re-enabling Servo for my development
builds.
I'll also second the notion that we need better build system support for
helping people select the right configuration for the task that they're
working on, but I think this is a better default for the general case.
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
--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation
If there was anything that depressed him more than his own cynicism,
it was that quite often it still wasn’t as cynical as real life.
--Terry Pratchett
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
