> [assertions expensive, etc]
(random suggestion): Why don't we profile the cost of all assertions,
or at least the number of times each is evaluated, across some some test
workload.
Then we'd have a quantitative basis on which to say "we can enable the
following set of assertions at the cost o
We already have implemented that static analysis but haven't enabled it
yet, because static analysis doesn't run on windows machines:
https://bugzilla.mozilla.org/show_bug.cgi?id=1223932
On Fri, Sep 23, 2016 at 12:51 PM, Bobby Holley
wrote:
> On Fri, Sep 23, 2016 at 9:30 AM, Ted Mielczarek
> wr
On Fri, Sep 23, 2016 at 9:30 AM, Ted Mielczarek wrote:
> On Fri, Sep 23, 2016, at 10:20 AM, Ehsan Akhgari wrote:
> > On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> > > Then this enables me to answer Ehsan's question. These are the builds
> > > I've recently tried using (e.g. when debugging inter
On Fri, Sep 23, 2016, at 10:20 AM, Ehsan Akhgari wrote:
> On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> > Then this enables me to answer Ehsan's question. These are the builds
> > I've recently tried using (e.g. when debugging intermittents in VMs
> > because then I don't need to set up too much
On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> On 23/09/2016 11:20, Ted Mielczarek wrote:
>> On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:
>>> I used to do that in the past, but nowadays artifact builds have changed
>>> the cost-benefit trade-off so very few people bother AFAIK, when no
On 2016-09-23 8:49 AM, Gijs Kruitbosch wrote:
> On 23/09/2016 11:20, Ted Mielczarek wrote:
>> On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:
>>> I used to do that in the past, but nowadays artifact builds have changed
>>> the cost-benefit trade-off so very few people bother AFAIK, when no
On 9/23/2016 1:49 PM, Gijs Kruitbosch wrote:
Then this enables me to answer Ehsan's question. These are the builds
I've recently tried using (e.g. when debugging intermittents in VMs
because then I don't need to set up too much of a build env) and they're
still very slow.
Some time ago I ventil
On 23/09/2016 11:20, Ted Mielczarek wrote:
On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:
I used to do that in the past, but nowadays artifact builds have changed
the cost-benefit trade-off so very few people bother AFAIK, when not
touching C++ code. If we could get artifact builds to
On Fri, Sep 23, 2016, at 05:58 AM, Panos Astithas wrote:
> I used to do that in the past, but nowadays artifact builds have changed
> the cost-benefit trade-off so very few people bother AFAIK, when not
> touching C++ code. If we could get artifact builds to use --enable-debug
> and --enable-optimi
On Thu, Sep 22, 2016 at 6:07 PM, Ehsan Akhgari
wrote:
> On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote:
> > On 22/09/2016 05:28, Nicholas Nethercote wrote:
> >> Greetings,
> >>
> >> Assertions, such as MOZ_ASSERT, are great. But they only run in debug
> >> builds.
> >>
> >> Release assertions, such
On 22/09/16 17:07, Ehsan Akhgari wrote:
> What exact debug configuration is too slow for you? People who want to
> debug C++ generally turn optimizations off, but for front-end devs, I
> think building with --enable-debug and --enable-optimize should give you
> an optimized build with the debug f
On 2016-09-22 9:07 AM, Gijs Kruitbosch wrote:
> On 22/09/2016 05:28, Nicholas Nethercote wrote:
>> Greetings,
>>
>> Assertions, such as MOZ_ASSERT, are great. But they only run in debug
>> builds.
>>
>> Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
>>
>> I want to highlight a n
Definitely explore this!
I want us to be very careful/deliberate about the privacy consequences of
this, though. Any values which could be user data need to be tightly
controlled, in the same manner we control access to the minidumps
themselves. So I don't think we should be too generic about this
On 09/22/2016 04:28 AM, Nicholas Nethercote wrote:
I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
this in nsTArray::ElementAt(), to implement a form of always-on array
bounds checking. See
https://bugzilla
On 22/09/2016 05:28, Nicholas Nethercote wrote:
Greetings,
Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.
Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
I want to highlight a nice case where converting a normal assertion
into a release asserti
On 9/22/2016 12:28 AM, Nicholas Nethercote wrote:
Greetings,
Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.
Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
I want to highlight a nice case where converting a normal assertion
into a release asser
+1 on MOZ_DIAGNOSTIC_ASSERT - its been very useful to me as well.
On Thu, Sep 22, 2016 at 6:40 AM, Bobby Holley wrote:
> There's also MOZ_DIAGNOSTIC_ASSERT, which is fatal in pre-release builds
> but not release ones. It can be a good compromise to find bugs in the wild
> when the performance co
There's also MOZ_DIAGNOSTIC_ASSERT, which is fatal in pre-release builds
but not release ones. It can be a good compromise to find bugs in the wild
when the performance cost is probably negligible but you're still not quite
comfortable shipping it on release. I added it last year while working on
s
Greetings,
Assertions, such as MOZ_ASSERT, are great. But they only run in debug builds.
Release assertions, such as MOZ_RELEASE_ASSERT, run in all builds.
I want to highlight a nice case where converting a normal assertion
into a release assertion was a win. In bug 1159244 Michael Layzell did
t
19 matches
Mail list logo
