Congratulations for this 20th issue of the newsletter and for all the hard work that the Quantum team is doing!
On Fri, Aug 18, 2017 at 7:36 PM, Olli Pettay <opet...@mozilla.com> wrote: > > > On 08/18/2017 08:28 PM, Ehsan Akhgari wrote: > >> On Fri, Aug 18, 2017 at 9:39 AM, Ryan VanderMeulen < >> rvandermeu...@mozilla.com <mailto: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!) >> > /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 >> >> >> On Fri, Aug 18, 2017 at 1:26 AM, Ehsan Akhgari < >> ehsan.akhg...@gmail.com <mailto: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_fire >> fox_nightly_for_few_weeksamazing/dlr05sl/>. :-) >> >> Moving on to mention one point about Speedometer charts on AWFY >> <https://arewefastyet.com/#machine=36&view=single&suite=spee >> dometer-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 <mailto:firefox-...@mozilla.org> >> https://mail.mozilla.org/listinfo/firefox-dev < >> https://mail.mozilla.org/listinfo/firefox-dev> >> >> >> >> >> >> -- >> Ehsan >> > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- <salva /> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
