Le 25/04/2018 à 18:26, Bobby Holley a écrit :
Could we instead have the profiler UI throw up a warning if the build was
not compiled with --enable-release?
I filed https://github.com/devtools-html/perf.html/issues/976 to discuss
about it.
Thanks,
--
Julien
On Wed, Apr 25, 2018 at 7:11 PM, Gregory Szorc wrote:
> 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.
This would be good to have. It would also help if such mozconfigs
On 04/25/2018 08:38 PM, Bobby Holley wrote:
On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote:
On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote:
At minimum we should make --enable-profiling build with rust-opt.
This sounds reasonable, although the quirk is that we default
--enab
On Wed, Apr 25, 2018 at 10:21 AM, Ted Mielczarek wrote:
> On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote:
> > At minimum we should make --enable-profiling build with rust-opt.
>
> This sounds reasonable, although the quirk is that we default
> --enable-profiling on for nightly[1], so any
On Wed, Apr 25, 2018, at 12:32 PM, Jeff Muizelaar wrote:
> At minimum we should make --enable-profiling build with rust-opt.
This sounds reasonable, although the quirk is that we default
--enable-profiling on for nightly[1], so anyone building m-c will have it
enabled. We could make the build sy
I think that makes sense as a default, with the ability to explicitly
--disable-release if people are profiling something specific, know what
they're doing, and want faster builds.
On Wed, Apr 25, 2018 at 9:32 AM, Jeff Muizelaar
wrote:
> At minimum we should make --enable-profiling build with ru
At minimum we should make --enable-profiling build with rust-opt.
-Jeff
On Wed, Apr 25, 2018 at 11:35 AM, Emilio Cobos Álvarez 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 lo
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
wrote:
>
>
> On 4/25/18 6:11 PM, Gregory Szorc wrote:
>
>>
>>
>> On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez wrote:
>>>
>>> The
On 4/25/18 6:11 PM, Gregory Szorc wrote:
On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez 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 cod
> On Apr 25, 2018, at 08:35, Emilio Cobos Álvarez 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
> optimiz
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
On 10/31/17 3:21 PM, Gregory Szorc wrote:
It is "wrong" for the set of "people performing profiling."
Just to be clear, that set is "everyone".
Now the set of "people performing profiling on builds they create
themselves" is a separate question
-Boris
___
On Tue, Oct 31, 2017 at 03:39:39PM -0400, Jeff Muizelaar wrote:
On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc wrote:
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 Gec
Would it be possible to have our profiling tools warn if about:compiler
optimization flags are not in about:buildconfig?
On Tue, Oct 31, 2017 at 3:39 PM, Jeff Muizelaar
wrote:
> On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc wrote:
> > On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar >
> > wro
On Tue, Oct 31, 2017 at 3:21 PM, Gregory Szorc wrote:
> On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar
> 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/iss
On Tue, Oct 31, 2017 at 12:21:42PM -0700, Gregory Szorc wrote:
On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar
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/
On Tue, Oct 31, 2017 at 12:02 PM, Jeff Muizelaar
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 "
On 31/10/17 19:30, Randell Jesup wrote:
Note that this means that profiles taken with local builds will be "off"
compared to Nightly/etc, unless you rebuild with extra options. How
much off? probably not a lot unless you're super-focused on Rust code,
but that's just a guess.
This was also th
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
-Jeff
On Thu, Oct 26, 2017 at 2:51 PM, Jeff Muizelaar wrote:
> FWIW, WebRender becomes unusab
>On 2017-10-25 1:34 PM, Gregory Szorc wrote:
>> 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.)
>
>I've added a note about this to our benchmarking instr
On 2017-10-25 1:34 PM, Gregory Szorc wrote:
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.)
I've added a note about this to our benchmarking instructions a
On 10/26/17 2:51 PM, Jeff Muizelaar wrote:
What's the use case for a
--enable-optimize, opt-level=1 build?
Fwiw, I ended up doing a fair amount of my work recently in a
"--enable-optimize, --disable-debug, --enable-rust-debug" build, for the
following reasons:
1) I was modifying Rust styl
On Thu, Oct 26, 2017 at 3:08 PM, Gregory Szorc wrote:
> Would it help if we had a separate --enable-optimize-rust (or similar)
> option to control Rust optimizations so we have separate knobs? If we did
> that, --disable-optimize-rust could be opt-level 0 or 1 and
> --enable-optimize-rust could be
On Thu, Oct 26, 2017 at 11:51 AM, Jeff Muizelaar
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
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
On Wed, Oct 25, 2017 at 10:34 AM, 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 o
On 10/25/17 2:50 PM, Emilio Cobos Álvarez wrote:
From mozilla-central I've been using ./mach cargo check gkrust, and I
certainly expect it to keep working.
Ah, excellent.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lis
On Wed, Oct 25, 2017 at 11:50 AM, Emilio Cobos Álvarez
wrote:
>
>
> On 10/25/2017 07:59 PM, Boris Zbarsky wrote:
> > On 10/25/17 1:34 PM, Gregory Szorc wrote:
> >> Also, due to ongoing work around Rust integration in the build system,
> it
> >> is dangerous to rely on manual `cargo` invocations t
On 10/25/2017 07:59 PM, Boris Zbarsky wrote:
> On 10/25/17 1:34 PM, Gregory Szorc wrote:
>> 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 bui
On 10/25/17 1:34 PM, Gregory Szorc wrote:
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 `car
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
31 matches
Mail list logo
