Quantum Flow Engineering Newsletter #20

[Ehsan Akhgari]

Hi everyone,

It is hard to believe that we've gotten to the twentieth of these
newsletters.  That also means that we're very quickly approaching the
finish line for this sprint.  We only have a bit more than five more weeks
to go before Firefox 57 merges to beta.  It may be a good time to start to
think more carefully about what we pay attention to in the remaining time,
both in terms of the risk of patches landing, and the opportunity cost of
what we decide to put off until 58 and the releases after.

We still have a large number of triaged bugs
 that are available for someone to pick up and work
on.  If you have some spare cycles, we really would appreciate if you
consider picking one or two bugs from this list and working on them.  They
span many different areas of the codebase so finding something in your area
of interest and expertise should hopefully be simple.  Quantum Flow isn't
the kind of project that requires fixing every single one of these bugs to
be finished successfully, but at the same time big performance improvements
often consist of many small parts, so the cumulative impact of a few
additional fixes can make a big impact.

It is worth mentioning that lately while lurking on various tech news and
blog sites where Nightly users comment, I have seen quite a few positive
comments about Nightly performance from users.  It's easy to get lost in
the details of the work involved in getting rid of synchronous IPCs,
synchronous layout/style flushes, unnecessary memory allocations, hashtable
lookups, improving data locality, JavaScript JIT performance, making sure
code gets inlined better, ship a new CSS engine, etc. etc. but it is
reassuring to see people 
take  notice
.
:-)

Moving on to mention one point about Speedometer charts on AWFY

which I have gotten a few questions about recently.  We now have
Speedometer benchmark numbers on Firefox Beta on the reference hardware
reported in addition to inbound optimized and PGO builds.  You may notice
that the benchmark score numbers we are getting on Beta are around the same
as Nightly (which swings around 83-84 these days).  This doesn't mean that
we haven't made any improvements on Nightly since the last Beta merge!  We
have some Nightly only telemetry code and some features that are only
enabled on the Nightly channel, and those add a bit of overhead, which
causes us to see a bit of an improvement after an uplift from
mozilla-central to mozilla-beta without any code changes.  This means that
when the current code on Nightly gets merged to Beta 57, we should expect a
bit of an improvement similarly.

And now let me take a moment to acknowledge the work of some of those who
helped make Firefox faster last week.  I hope I'm not dropping anyone's
name mistakenly.

   - Perry Jiang made _shouldCapture() run off of the idle queue and do
   nothing for about: pages
   . Perry also made
   it so that we don’t unnecessarily load the autoscroll PNG when opening a
   new window.
   - Kris Maglione fixed a recent regression causing extremely poor
   performance with extensions which have scripts creating large numbers of
   message listeners which never call their response callbacks
   .  He also made
   code that registers a lot of lazy module and service getters use loops
    to make such code
   easier to optimize by SpiderMonkey JIT.  He furthermore switched away
   from using FileUtils.getFile()
    which does
   main-thread I/O to check for the respective directory exists.  Kris also
   made us not create the IndexedDB bindings in sandboxes
    since they’re
   never used and avoided adding the caller location to the sandbox name if
   an explicit name if provided by the caller
   .
   - Jan de Mooij added a megamorphic SetElement stub
   .  He also optimized
   ToPropertyKey a bit
   .
   - Nicolas B. Pierron optimized the LIRGenerator/CodeGenerator snapshot
   code .
   - André Bargull removed some unnecessary allocations and rooting in the
   RegExp code .  He
   also moved Array.prototype.sort entry point to self-hosted JS code
   

Re: Proposed W3C Charter: WebVR Working Group

[Tantek Çelik]

Given that we have a day left to respond to this poll, we should begin
writing up at least a draft answer with known facts that we can
iterate on as we get more information.

Rough draft WebVR proposed charter response points for consideration:


1. Timing is good. We think WebVR is ready for a WG to formally standardize it.

[Our very action of shipping a WebVR feature publicly (without pref)
speaks louder than any words on any email lists (including this one)
and communicates that we think WebVR is ready for adoption on the open
web (if that were not true, we should not be shipping it publicly, but
my understanding is that that decision has been made.), and thus ready
for rapid standardization among implementers.]

2. WG charter details bad. We have strong concerns about the proposed
WG charter as written, including apparent disconnects with the CG, and
in particular failure to involve  implementers (e.g. browser vendors
and major hardware providers).

3. Conclusion: Formal objection. Charter bad, needs to be withdrawn,
be rewritten in an open dialog with the CG, such that there is at
least rough consensus with the CG on scope, chairs, and other details.


I believe these points reflect our actions and what Lars has communicated below:

On Thu, Aug 17, 2017 at 9:14 AM, Lars Bergstrom  wrote:
> I'll follow up more with the chairs of the community group (they just had a
> face to face earlier this week and I presume it came up). The last bit that
> I heard is consistent with what Dan mentioned -  the concern is not around
> standardization

Thanks for the clarification, thus point 1.

> but that neither the chairs nor the browser vendors nor the
> major hardware providers were consulted publicly in the creation of a
> proposal to transition to a working group:
> https://lists.w3.org/Archives/Public/public-webvr/2017Jul/0083.html

Thus point 2.

> Based on that thread, I'd expect the proposal to be withdrawn or - as Dan
> mentioned - things adjusted to involve the the current spec contributors.

Thus point 3 - we should openly advocate for the proposed charter to
be withdrawn and rewritten accordingly.


> I'll try to get on the phone with folks to find out more and get something
> to dbaron by tomorrow. I'm not familiar with the inner workings of the W3C,
> but I find it hard to imagine how things will go well with none of the
> current spec contributors involved.

Short answer: historically when W3C WGs move forward without strong
implementer participation, they have very low chances of success, high
chances of failure, and especially of damaging good will in relevant
communities. Your concerns are merited.

More information definitely appreciated to help iterate on our response.

Thanks Lars,

Tantek


> On Wed, Aug 16, 2017 at 10:46 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Aug 16, 2017 at 5:18 PM, Daniel Veditz 
>> wrote:
>>
>>> On Wed, Aug 16, 2017 at 3:51 PM, L. David Baron 
>>> wrote:
>>>
>>> > I still think opposing this charter because the group should still
>>> > be in the incubation phase would be inconsistent with our shipping
>>> > and promotion of WebVR.
>>> >
>>>
>>> I agree that would be exceptionally odd and require a well reasoned
>>> argument about why formal standardization was inappropriate.
>>>
>>
>> This puzzles me as well. Lars, can you explain what the argument against
>> standardization of a shipping feature is?
>>
>> -Ekr
>>
>>
>>>
>>> I'm troubled that the members of the incubation group seem to feel that
>>> chairs are being imposed on them who have been less involved (or
>>> uninvolved?) with leading the feature to the point it's gotten so far. But
>>> I don't understand the politics of that or whether we could or should get
>>> involved on that point.
>>>
>>> -Dan Veditz
>>> ___
>>> 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

Re: refcounting - which types to use ?

[Aryeh Gregor]

On Thu, Aug 17, 2017 at 7:07 AM, Enrico Weigelt, metux IT consult
 wrote:
> OTOH, is there a way to create versions that really return it as rval,
> so I conveniently could just call like that ?
>
>nsCOMPtr list = addrbook->FindRecipients(addr);

You can do this with a return type of
already_AddRefed.  Then instead of

  list.forget(_retval);
  return NS_OK;

you do just

  return list.forget();

Note that in this case you cannot ignore the return value -- it must
be assigned to an nsCOMPtr or a RefPtr, or else it will leak.  Ideally
we would allow a return type of nsCOMPtr&&, but
currently I think we don't.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Response.body streams landing on trunk, default off

[Jean-Yves Avenard]

> On 14 Aug 2017, at 4:14 pm, Ben Kelly  wrote:
> 
> FYI, the Fetch API side of streams has landed and is now in nightly.
> Please test and file bugs.  Thanks!
> 
> Ben

Awesome thank you.

JY
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform