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
<https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3A"[qf%3Ap"
%40nobody%40mozilla.org> 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 <https://news.ycombinator.com/item?id=14977352>
take <https://twitter.com/fabi1cazenave/status/898260768419917824> notice
<https://www.reddit.com/r/firefox/comments/6u9kwx/tried_firefox_nightly_for_few_weeksamazing/dlr05sl/>.
:-)

Moving on to mention one point about Speedometer charts on AWFY
<https://arewefastyet.com/#machine=36&view=single&suite=speedometer-misc&subtest=score>
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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353584>. 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
<https://bugzilla.mozilla.org/show_bug.cgi?id=1389381>. He also made
code that registers a lot of lazy module and service getters use loops
<https://bugzilla.mozilla.org/show_bug.cgi?id=1388215> to make such code
easier to optimize by SpiderMonkey JIT. He furthermore switched away
from using FileUtils.getFile()
<https://bugzilla.mozilla.org/show_bug.cgi?id=1388208> which does
main-thread I/O to check for the respective directory exists. Kris also
made us not create the IndexedDB bindings in sandboxes
<https://bugzilla.mozilla.org/show_bug.cgi?id=1389868> since they’re
never used and avoided adding the caller location to the sandbox name if
an explicit name if provided by the caller
<https://bugzilla.mozilla.org/show_bug.cgi?id=1389847>.
- Jan de Mooij added a megamorphic SetElement stub
<https://bugzilla.mozilla.org/show_bug.cgi?id=1388388>. He also optimized
ToPropertyKey a bit
<https://bugzilla.mozilla.org/show_bug.cgi?id=1388354>.
- Nicolas B. Pierron optimized the LIRGenerator/CodeGenerator snapshot
code <https://bugzilla.mozilla.org/show_bug.cgi?id=1388014>.
- André Bargull removed some unnecessary allocations and rooting in the
RegExp code <https://bugzilla.mozilla.org/show_bug.cgi?id=1387968>. He
also moved Array.prototype.sort entry point to self-hosted JS code
<https://bugzilla.mozilla.org/show_bug.cgi?id=1383648> in order to avoid
frequent C++ to JS calls when sorting an array with a comparator argument
present.
- Zibi Braniecki got rid of expensive per-option element styling that we
used to have for select boxes in e10s mode
<https://bugzilla.mozilla.org/show_bug.cgi?id=1386015>.
- Adam Gashlin made us use a low priority timer for Places expiration
<https://bugzilla.mozilla.org/show_bug.cgi?id=1376533>.
- Henri Sivonen made the HTML parser atomize class attribute values for
the class of single class values when parsing innerHTML strings
<https://bugzilla.mozilla.org/show_bug.cgi?id=1375701>. This speeds up
parsing HTML strings used in innerHTML setters that have class=”foo”
attributes.
- Ting-Yu Chou ensured that we calculate the spill weight of a range's
uses when we add to or remove from it
<https://bugzilla.mozilla.org/show_bug.cgi?id=1385165>, as opposed to
the cache unfriendly iteration over the range's uses to calculate this
information when needed.
- Mason Chang got rid of some graphics overhead
<https://bugzilla.mozilla.org/show_bug.cgi?id=1372602> that we had
accidentally accumulated on the hidden window on macOS.
- Edouard Oger ensured that the sync-illustration SVG is not loaded
until it’s needed <https://bugzilla.mozilla.org/show_bug.cgi?id=1380377>.
- Jonathan Watt avoided some hashtable lookups in undisplayed maps for
elements without display:none or display:contents children
<https://bugzilla.mozilla.org/show_bug.cgi?id=1367214>.
- Blake Kaplan avoided some unneeded sync IPC for performing URI fix-up
by creating a URI object explicitly in the content process
<https://bugzilla.mozilla.org/show_bug.cgi?id=1375243>.
- Jonathan Kew avoided some memory allocation churn in
gfxFont::GetRoundOffsetsToPixels()
<https://bugzilla.mozilla.org/show_bug.cgi?id=1377257>.

Cheers,
--
Ehsan

[Ryan VanderMeulen]

Is there a good way to get a sense of what the higher-impact bugs are that
remain for improving Speedometer? Just going through the deps is difficult
because it's hard to assess how much of a win some of those are. Are we
gated mostly on JS perf at this point? Layout? Something else? :-)

Thanks!

-Ryan

On Fri, Aug 18, 2017 at 1:26 AM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> 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

> <https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3A%22[qf%3Ap%22%20%40nobody%40mozilla.org>

> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>

[Ehsan Akhgari]

On Fri, Aug 18, 2017 at 9:39 AM, Ryan VanderMeulen <
rvande...@mozilla.com> wrote:

> Is there a good way to get a sense of what the higher-impact bugs are that
> remain for improving Speedometer? Just going through the deps is difficult
> because it's hard to assess how much of a win some of those are. Are we
> gated mostly on JS perf at this point? Layout? Something else? :-)
>

That's a pretty hard question to answer since in many cases the impact of
each individual bug fix may fall below the measurement noise in the
benchmark score, and also it's pretty hard to map what you see in profiles
to benchmark score numbers, except for bugs that have some kind of in
progress patch which allows us to measure the before and after state
without them having been fixed yet.

In general Speedometer performance isn't generally gated on anything
extremely big and instead has been improved by fixing many small
performance issues all over the place. That being said, there are some
"high profile" bugs that come to my mind. Jan may think of some more in
SpiderMonkey:

* https://bugzilla.mozilla.org/show_bug.cgi?id=651120 I think will be
able to gain us a few extra points but it's a complex change with many
dependencies and a few people are helping out Cătălin with it.
(Interestingly I just realized it wasn't on the dependency list of the main
SM2 bug!)
* https://bugzilla.mozilla.org/show_bug.cgi?id=1346723 may also help some
more still. We have already done a ton of work under that bug, but there's
some more work to be done. However this bug is getting closer to the state
where most of the remaining work involves fixing many different issues,
each of which is costing a bit of the overall time spent there when running
the benchmark.
* https://bugzilla.mozilla.org/show_bug.cgi?id=1349255 is a sync IPC that
hurts Speedometer so fixing it may have an outsized impact relative to
other bug fixes.
* https://bugzilla.mozilla.org/show_bug.cgi?id=1377131 may have a large
impact also, but I'm not sure exactly how much. Olli may be able to
provide more information about that.

Cheers,
Ehsan

--
Ehsan

[Olli Pettay]

On 08/18/2017 08:28 PM, Ehsan Akhgari wrote:

> On Fri, Aug 18, 2017 at 9:39 AM, Ryan VanderMeulen <rvande...@mozilla.com <mailto:rvande...@mozilla.com>> wrote:
>
> Is there a good way to get a sense of what the higher-impact bugs are that remain for improving Speedometer? Just going through the deps is
> difficult because it's hard to assess how much of a win some of those are. Are we gated mostly on JS perf at this point? Layout? Something else? :-)
>
>
> That's a pretty hard question to answer since in many cases the impact of each individual bug fix may fall below the measurement noise in the
> benchmark score, and also it's pretty hard to map what you see in profiles to benchmark score numbers, except for bugs that have some kind of in
> progress patch which allows us to measure the before and after state without them having been fixed yet.
>
> In general Speedometer performance isn't generally gated on anything extremely big and instead has been improved by fixing many small performance
> issues all over the place. That being said, there are some "high profile" bugs that come to my mind. Jan may think of some more in SpiderMonkey:
>
> * https://bugzilla.mozilla.org/show_bug.cgi?id=651120 I think will be able to gain us a few extra points but it's a complex change with many
> dependencies and a few people are helping out Cătălin with it. (Interestingly I just realized it wasn't on the dependency list of the main SM2 bug!)

/me would like to see some Speedometer numbers from a build with the patches for bug 651120

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1346723 may also help some more still. We have already done a ton of work under that bug, but
> there's some more work to be done. However this bug is getting closer to the state where most of the remaining work involves fixing many different
> issues, each of which is costing a bit of the overall time spent there when running the benchmark.
> * https://bugzilla.mozilla.org/show_bug.cgi?id=1349255 is a sync IPC that hurts Speedometer so fixing it may have an outsized impact relative to
> other bug fixes.

I thought this would affect Speedometer significantly, since it shows up in the profiles, but I disabled the sync message altogether and rerun and
couldn't really see difference locally. Perhaps the sync calls happen usually when Speedometer isn't running tests but just loading pages or so.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1377131 may have a large impact also, but I'm not sure exactly how much. Olli may be able to provide
> more information about that.

Locally my patches seem to affect quite a lot on linux, but unfortunately less on Windows.

>
> Cheers,
> Ehsan
>
>
> Thanks!
>
> -Ryan

> * Perry Jiang made _shouldCapture() run off of the idle queue and do nothing for about: pages

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1353584>. 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1389381>. He also made code
> that registers a lot of lazy module and service getters use loops <https://bugzilla.mozilla.org/show_bug.cgi?id=1388215> to make such code
> easier to optimize by SpiderMonkey JIT. He furthermore switched away from using FileUtils.getFile()
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1388208> which does main-thread I/O to check for the respective directory exists. Kris also
> made us not create the IndexedDB bindings in sandboxes <https://bugzilla.mozilla.org/show_bug.cgi?id=1389868> since they’re never used and
> avoided adding the caller location to the sandbox name if an explicit name if provided by the caller
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1389847>.

> * Jan de Mooij added a megamorphic SetElement stub <https://bugzilla.mozilla.org/show_bug.cgi?id=1388388>. He also optimized ToPropertyKey

> a bit <https://bugzilla.mozilla.org/show_bug.cgi?id=1388354>.

> * Nicolas B. Pierron optimized the LIRGenerator/CodeGenerator snapshot code <https://bugzilla.mozilla.org/show_bug.cgi?id=1388014>.
> * André Bargull removed some unnecessary allocations and rooting in the RegExp code <https://bugzilla.mozilla.org/show_bug.cgi?id=1387968>.

> He also moved Array.prototype.sort entry point to self-hosted JS code <https://bugzilla.mozilla.org/show_bug.cgi?id=1383648> in order to
> avoid frequent C++ to JS calls when sorting an array with a comparator argument present.

> * Zibi Braniecki got rid of expensive per-option element styling that we used to have for select boxes in e10s mode
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1386015>.
> * Adam Gashlin made us use a low priority timer for Places expiration <https://bugzilla.mozilla.org/show_bug.cgi?id=1376533>.
> * Henri Sivonen made the HTML parser atomize class attribute values for the class of single class values when parsing innerHTML strings

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1375701>. This speeds up parsing HTML strings used in innerHTML setters that have
> class=”foo” attributes.

> * Ting-Yu Chou ensured that we calculate the spill weight of a range's uses when we add to or remove from it

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1385165>, as opposed to the cache unfriendly iteration over the range's uses to calculate
> this information when needed.

> * Mason Chang got rid of some graphics overhead <https://bugzilla.mozilla.org/show_bug.cgi?id=1372602> that we had accidentally accumulated

> on the hidden window on macOS.

> * Edouard Oger ensured that the sync-illustration SVG is not loaded until it’s needed <https://bugzilla.mozilla.org/show_bug.cgi?id=1380377>.
> * Jonathan Watt avoided some hashtable lookups in undisplayed maps for elements without display:none or display:contents children
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1367214>.
> * Blake Kaplan avoided some unneeded sync IPC for performing URI fix-up by creating a URI object explicitly in the content process
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1375243>.
> * Jonathan Kew avoided some memory allocation churn in gfxFont::GetRoundOffsetsToPixels()

> <https://bugzilla.mozilla.org/show_bug.cgi?id=1377257>.
>
> Cheers,
> --
> Ehsan
>
> _______________________________________________
> firefox-dev mailing list

> firef...@mozilla.org <mailto:firef...@mozilla.org>
> https://mail.mozilla.org/listinfo/firefox-dev <https://mail.mozilla.org/listinfo/firefox-dev>
>
>
>
>
>
> --
> Ehsan

[Salvador de la Puente]

Congratulations for this 20th issue of the newsletter and for all the hard
work that the Quantum team is doing!

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>



--
<salva />