On 4/25/18 6:11 PM, Gregory Szorc wrote:
On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez <emi...@crisal.io> wrote:
There's a fair amount of people bitten by this constantly, which see long style
profiling markers and what's really happening is that they're profiling a local
opt build, and thus the Rust code in style has barely any optimization and is
slow.
I know that shouldn't be a thing, and that people should --enable-release for
profiling and all that. But given it happens, could we consider reverting this
change?
I’m going to assert that the set of people who care about fast builds is
greater than the set of people who care about profiling the style system on
local builds. Do you disagree? Or is the slowness of the style system
undermining the ability for the local build to be usable/useful in general?
This is not about people profiling the style system, I couldn't disagree
with that.
This is about people doing general profiling, or profiling unrelated
stuff, which see that the style system takes half of the time on their
testcase, when in proper release builds it's a minor amount of the total
time.
Regardless, I think the most productive conversation we can have is about how
we can make the Firefox development UI guide people towards an optimal build
configuration. The reality is that there are several “factions” of developers
that each want different things from a build. There is no
one-build-config-fits-all.
The build peers have long thought about adding the concept of “build profiles”
to the build system. Think of them as in-tree mozconfigs for common, supported
scenarios.
But without a forcing function making people choose an initial “profile,”
people will continue to get bit by whatever default we choose.
We once printed a fatal message on first invocation of the build system. This
was intended to be such a forcing function. But there was popular revolt and
this feature was removed. Considering that I managed to upset a lot of people
with this feature, I’m reluctant to go down that path again because it would
seemingly undermine general support for the build system team and jeopardize
our ability to make meaningful changes.
On 10/25/17 7:34 PM, Gregory Szorc 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
_______________________________________________
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
