On Fri, Aug 18, 2017 at 9:39 AM, Ryan VanderMeulen < rvandermeu...@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 > 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 >> >> > -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
