Quantum Flow Engineering Newsletter #20

Ryan VanderMeulen rvandermeulen at mozilla.com
Fri Aug 18 13:39:46 UTC 2017

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? :-)



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

> 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>
> 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
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20170818/46778aab/attachment.html>

More information about the firefox-dev mailing list