Could we instead have the profiler UI throw up a warning if the build was not compiled with --enable-release?
On Wed, Apr 25, 2018 at 9:23 AM, Emilio Cobos Álvarez <emi...@crisal.io> wrote: > > > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
