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.akhg...@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> > 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-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
