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_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 <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
