> 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? 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
