Quantum Flow Engineering Newsletter #5

[Ehsan Akhgari]

Hi everyone,

Another week full of performance related updates quickly went by, I'd like
to share a few of them.

We're almost mid-April, about 3 weeks after I shared my first update
<https://ehsanakhgari.org/blog/2017-03-23/quantum-flow-engineering-newsletter-3>
on our progress battling our sync IPC issues. I have prepared a second Sync
IPC Report for 2017-04-13
<https://docs.google.com/spreadsheets/d/1x_BWVlnQPg0DHbsrvPFX7g89lnFGa3lAIHWD_pLa_dE/edit#gid=997870905&fvid=1346771801>.
For those who looked at the previous report, this is in the same
spreadsheet, and the data is next to the previous report, for easy
comparison. We have made a lot of great progress fixing some of the really
bad synchronous IPC issues in the recent few weeks, and even though
telemetry data is laggy, we are starting to see this reflect in the data
coming in through telemetry! Here is a human readable summary of where we
are now:

- PCookieService::Msg_GetCookieString
<https://bugzilla.mozilla.org/show_bug.cgi?id=1331680> is still at the
top of the list, now taking a whopping 45% piece of the pie chart! I don't
think there is any reason to believe that this has gotten particularly
worse, it's just that we're starting to get better at not doing synchronous
IPC, so this is standing out even more now! But its days are numbered. :-)
- PContent::Msg_RpcMessage and PBrowser::Msg_RpcMessage at 19%. We
still need to get better data about the sync IPC triggered from JS, that
shows up in this data under one of these buckets.
- PJavaScript::Msg_Get at 5% (CPOW overhead) could be caused by add-ons
that aren't e10s compatible.
- PAPZCTreeManager::Msg_ReceiveMouseInputEvent. This one (and a few
other smaller APZ related ones) tends to have really low mean values, but
super high count values which is why they tend to show high on this list,
but they aren't necessarily too terrible compared to the rest of our sync
IPC issues.
- PVRManager::Msg_GetSensorState
<https://bugzilla.mozilla.org/show_bug.cgi?id=1346927> also relatively
low mean values but could be slightly worse.
- PJavaScript::Msg_CallOrConstruct, more CPOW overhead.
- PContent::Msg_SyncMessage, more JS triggered sync IPC.

A few items further down on the list are either being worked on or recently
fixed as well. I expect this to keep improving over the next few weeks.
It is really great to see this progress, thanks to everyone who has worked
on fixing these issues, helping with the diagnoses, code reviews, etc.

We have also been working hard at triaging performance related bug
reports. In order to keep an eye over the bug-to-bug status of project you
can use the Bugzilla queries on the wiki
<https://wiki.mozilla.org/Quantum/Flow#Bugzilla_Query_Lists>. As of this
moment, we have triaged 160 bugs as [qf:p1] (which means, these performance
related bugs are the ones we believe should be fixed now for the Firefox 57
release). Of these bugs, 92 bugs are unassigned right now. If you see a
bug on this list in your area of expertise which you think you can help
with, please consider picking it up. We really appreciate your help.
Please remember that not every bug on this list is complicated to fix, and
there's everything from major architectural changes to simple one-liner
fixes up for grabs. :-)

Another really nice effort that is starting to unfold and I'm super excited
about is the new Photon performance project
<https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>, which is a focused
effort on the front-end performance. This includes everything from
engineering the new UI with things like animations running on the
compositor in mind from the get-go, being laser focused on guaranteeing
good performance on key UI interactions such as tab opening and closing,
and lots of focused measurements and fixes to the browser front-end.

The performance story of this week is about how measurement tools can
distort our vision. And this one isn't much of a story, it's more of a
lesson that I have been learning seemingly over and over again, these
days. You may have heard of the measurement problem
<https://en.wikipedia.org/wiki/Measurement_problem>, which basically
amounts to the fact that you always change what you measure. Markus and I
were recently talking about the cost of style flushes for browser.xul that
I had seen in my profiles and how they could sometimes be expensive, and
noticed that this may be due to the profiler overhead
<https://bugzilla.mozilla.org/show_bug.cgi?id=1354255> that we incur in
order to show information about the cause of the restyle in the profile
UI. He fixed the issue since. I think the reason why I didn't catch this
in my own profiling was that I have gotten so used to seeing expensive
reflows and restyles that sometimes I accept that as a fact of life and
don't look under the hood closely enough. Lesson learned!

We have a bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1329212>
tracking these types of issues, so if you know of something similar please
create a dependency. If you also profile Firefox regularly using the Gecko
Profiler, adding yourself to the CC list of that bug may not be a bad idea.


Now it's time to acknowledge those who have helped make Firefox faster in
the past week. I will probably forget a few people here, apologies for any
unintended omissions!


- Tim Taubert made a couple
<https://bugzilla.mozilla.org/show_bug.cgi?id=912717> of fixes
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353533> to the
performance of SessionCookies.jsm code, which, IINM runs periodically on
the UI thread and during startup. Well done!
- Henry Chang continued
<https://bugzilla.mozilla.org/show_bug.cgi?id=1343425> his work on
improving url-classifier performance.
- David Keeler disabled an expensive telemetry probe
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353216> which could slow
down HTTPS page loads by up to 2 times in certain cases.
- Jonathan Kew added some caching to
gfxFontShaper::GetRoundOffsetsToPixels()
<https://bugzilla.mozilla.org/show_bug.cgi?id=1352528>.
- Olli Pettay enabled high priority vsync events in the parent process
<https://bugzilla.mozilla.org/show_bug.cgi?id=1352523>. This seems to
have finally stuck. Olli was trying to get this landed for months now, and
our unit tests disagreed. :-)
- Kyle Machulis restricted the plugin finding/initialization code to
Flash/PDF <https://bugzilla.mozilla.org/show_bug.cgi?id=1351490>,
lowering the overhead of the expensive MIME type lookups we used to do.
- JW Wang fixed a bug
<https://bugzilla.mozilla.org/show_bug.cgi?id=1354389> where we were
blocking the main thread for file I/O done on a background thread for up to
8 seconds according to telemetry data. Readers of this newsletters should
be familiar with this anti-pattern now...
- Gerald Squelart fixed a
<https://bugzilla.mozilla.org/show_bug.cgi?id=1337063> graphics
initialization synchronous IPC issue. This could be a navigation
performance issue with multi-e10s.
- Evelyn Hung lowered the cost of size calculation
<https://bugzilla.mozilla.org/show_bug.cgi?id=1355595> for the height of
the squiggly line we draw for misspelled words during spell checking.
- Marco Bonardo removed a sync reflow
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353708> which caused jank
when opening the awesomebar panel.
- Dão Gottwald also removed a sync reflow loop
<https://bugzilla.mozilla.org/show_bug.cgi?id=1354782> which caused jank
when resizing windows with pinned tabs.
- Masatoshi Kimura added a cache
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353493> for the
preference access in nsIWidget::DefaultScaleOverride().
- Jan de Mooij further improved the external string cache
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353758> by moving it into
the JS engine. He also improved our SetProp failure rate
<https://bugzilla.mozilla.org/show_bug.cgi?id=1336580> on sites like
Google Spreadsheets.
- Kartikaya Gupta removed a synchronous IPC
<https://bugzilla.mozilla.org/show_bug.cgi?id=1350638> from the
compositor.
- Makoto Kato avoided using synchronous IPC
<https://bugzilla.mozilla.org/show_bug.cgi?id=1330912> to set the
spellchecker dictionary language.
- Neil Deakin removed a sync reflow
<https://bugzilla.mozilla.org/show_bug.cgi?id=1334635> that happened
when closing a window.
- Mike Conley started to create an add-on
<https://mikeconley.github.io/ohnoreflow/> helping front-end engineers
in finding sync reflow issues in the browser UI.


Until next week, happy hacking!

--
Ehsan

[Jack Moffitt]

> Another really nice effort that is starting to unfold and I'm super excited
> about is the new Photon performance project
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>, which is a focused
> effort on the front-end performance. This includes everything from
> engineering the new UI with things like animations running on the
> compositor in mind from the get-go, being laser focused on guaranteeing
> good performance on key UI interactions such as tab opening and closing,
> and lots of focused measurements and fixes to the browser front-end.

I think the order of operations here is unfortunate. What we'd prefer
is that WebRender land first, and then Photon be designed around what
is possible in the GPU-backed world. This ordering means that Photon
will be optimized for operations that all the other engines already
optimize, whereas the WebRender-first order would get us UI that is
previously out of reach for web content. It would be an excellent way
to show off WebRender's benefits since we can't expect web content to
adapt immediately. We have some experimental results from browser.html
that showed there are plenty of cases where Servo gave smooth
performance for real animations the developers wanted to create that
weren't smooth in other engines.

I imagine there are other pieces that benefit both backends, but I
thought I'd point out that specifically for compositor backed
operations, the set of those is quite different between current Gecko
and WebRender.

jack.

[Eric Rescorla]

On Tue, Apr 18, 2017 at 4:19 AM, Jack Moffitt <ja...@metajack.im> wrote:

> > Another really nice effort that is starting to unfold and I'm super
> excited
> > about is the new Photon performance project
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>, which is a
> focused
> > effort on the front-end performance. This includes everything from
> > engineering the new UI with things like animations running on the
> > compositor in mind from the get-go, being laser focused on guaranteeing
> > good performance on key UI interactions such as tab opening and closing,
> > and lots of focused measurements and fixes to the browser front-end.
>
> I think the order of operations here is unfortunate. What we'd prefer
> is that WebRender land first, and then Photon be designed around what
> is possible in the GPU-backed world.

When will that landing be? How much time will that leave for designing
photon?

-Ekr

[Milan Sreckovic]

Jack are you speaking in the context of Servo?

From the Quantum Render (Gecko with the WebRender evolution we're
working on) point of view, Proton should not count on anything getting
better. In other words, design for Firefox 55 and assume things will
not get worse. If you need them to get better, come talk to the
graphics team. There are currently no such requirements I'm aware of,
specifically tied to the Proton work.

So, I don't see the order of operations being an issue, but I could be
missing something Jack knows of.

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
- Milan (mi...@mozilla.com)

[Justin Dolske]

On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt <ja...@metajack.im> wrote:

> > Another really nice effort that is starting to unfold and I'm super
> excited
> > about is the new Photon performance project
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>, which is a
> focused
> > effort on the front-end performance. This includes everything from
> > engineering the new UI with things like animations running on the
> > compositor in mind from the get-go, being laser focused on guaranteeing
> > good performance on key UI interactions such as tab opening and closing,
> > and lots of focused measurements and fixes to the browser front-end.
>
> I think the order of operations here is unfortunate. What we'd prefer
> is that WebRender land first, and then Photon be designed around what
> is possible in the GPU-backed world.

That's a complete non-starter. Photon work is already underway, and there's
a _ton_ of work to do for the 57 release.

Blocking Photon on another major project landing first would mean canceling
Photon for 57.

Justin

[Jared Wein]

But what we *can* do is have communications with the WebRender devs to see
that our approaches (which have been mostly vetted by graphics and layout
people already) will continue to perform well (and possibly better) in
WebRender.

> _______________________________________________
> firefox-dev mailing list
> firef...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>

[Ehsan Akhgari]

On 2017-04-18 1:53 PM, Justin Dolske wrote:
>
>
> On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt <ja...@metajack.im
> <mailto:ja...@metajack.im>> wrote:
>
> > Another really nice effort that is starting to unfold and I'm super excited
> > about is the new Photon performance project
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>>, which is a
> focused
> > effort on the front-end performance. This includes everything from
> > engineering the new UI with things like animations running on the
> > compositor in mind from the get-go, being laser focused on guaranteeing
> > good performance on key UI interactions such as tab opening and closing,
> > and lots of focused measurements and fixes to the browser front-end.
>
> I think the order of operations here is unfortunate. What we'd prefer
> is that WebRender land first, and then Photon be designed around what
> is possible in the GPU-backed world.
>
>
> That's a complete non-starter. Photon work is already underway, and
> there's a _ton_ of work to do for the 57 release.

If I can clarify a bit, the main goal of Photon isn't to be a showcase
of WebRender capabilities. The main goal of that project is to get a
much more responsive UI than what we currently have. Obviously for the
implementation we would love to use every bit of power that Gecko
provides, but we can't rely on anything that will not be 100% certainly
be part of the 57 release. The last time I checked with the graphics
team, at this point it's completely unclear whether Quantum Render is
going to make it, and as such, it's not reasonable for us to depend on
anything that WebRender provides for Photon, because if QR wouldn't make
it to 57 then we wouldn't have a backup plan.

All in all we have a lot of ongoing projects and they each have
different scales and different degrees of risk associated with them, and
we are trying hard to be really careful on what project depends on what
other project to try to protect ourselves from cases where project X
doesn't make it in time taking project Y down with it. :-) Photon is
such an important piece of the puzzle that making it depend on anything
that isn't super certain is extremely risky, and without Photon the
entire release plan for the whole Quantum is going to be jeopardized,
and that isn't an acceptable risk.

I hope this helps make the plans make more sense. If they still don't,
I'm happy to answer more questions!

Cheers,
Ehsan

[Chris Peterson]

On 2017-04-18 4:22 PM, Ehsan Akhgari wrote:
> The last time I checked with the graphics
> team, at this point it's completely unclear whether Quantum Render is
> going to make it, and as such, it's not reasonable for us to depend on
> anything that WebRender provides for Photon, because if QR wouldn't make
> it to 57 then we wouldn't have a backup plan.

In addition, AFAIK, only about half of Firefox Windows users have GPUs
that are compatible with WebRender acceleration. We need Photon to
perform well for users stuck on the software rendering path.

[Jack Moffitt]

I was not saying the plans don't make sense, only that the ordering
turns out to be unfortunate. I am also not suggesting we modify the
plan, as the WebRender trajectory is not conducive to being a blocker
for any work planed for 57 (as has been pointed out). I do think
people should keep WebRender in mind and not overly design for 57, or
at least not put in constraints we can't undo easily once they are not
necessary.

Regarding the percentage of users who have GPUs, I would suggest we
keep in mind that since we want to win back users to Firefox we
shouldn't be judging new engine features by the small population of
current users, but by the population of users who might switch. If we
build an engine that is a lot better for people with GPUs, you can
expect those people will be more motivated to try it out. Our target
audience is much larger than our existing users, and may have quite
different hardware profiles.

jack.

On Tue, Apr 18, 2017 at 5:22 PM, Ehsan Akhgari <ehsan....@gmail.com> wrote:
> On 2017-04-18 1:53 PM, Justin Dolske wrote:
>>
>>
>> On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt <ja...@metajack.im
>> <mailto:ja...@metajack.im>> wrote:
>>
>> > Another really nice effort that is starting to unfold and I'm super excited
>> > about is the new Photon performance project
>> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>>, which is a
>> focused
>> > effort on the front-end performance. This includes everything from
>> > engineering the new UI with things like animations running on the
>> > compositor in mind from the get-go, being laser focused on guaranteeing
>> > good performance on key UI interactions such as tab opening and closing,
>> > and lots of focused measurements and fixes to the browser front-end.
>>
>> I think the order of operations here is unfortunate. What we'd prefer
>> is that WebRender land first, and then Photon be designed around what
>> is possible in the GPU-backed world.
>>
>>
>> That's a complete non-starter. Photon work is already underway, and
>> there's a _ton_ of work to do for the 57 release.
>
> If I can clarify a bit, the main goal of Photon isn't to be a showcase
> of WebRender capabilities. The main goal of that project is to get a
> much more responsive UI than what we currently have. Obviously for the
> implementation we would love to use every bit of power that Gecko
> provides, but we can't rely on anything that will not be 100% certainly

> be part of the 57 release. The last time I checked with the graphics

> team, at this point it's completely unclear whether Quantum Render is
> going to make it, and as such, it's not reasonable for us to depend on
> anything that WebRender provides for Photon, because if QR wouldn't make
> it to 57 then we wouldn't have a backup plan.
>

[Justin Dolske]

On Tue, Apr 18, 2017 at 4:22 PM, Ehsan Akhgari <ehsan....@gmail.com>
wrote:

> All in all we have a lot of ongoing projects and they each have
> different scales and different degrees of risk associated with them, and
> we are trying hard to be really careful on what project depends on what
> other project to try to protect ourselves from cases where project X
> doesn't make it in time taking project Y down with it. :-)
>
>

In short, we're trying to avoid Quantum entanglement. :D :D

Justin

[Milan Sreckovic]

I will repeat what I said earlier, and I should know, because I'm
running Quantum Render. There was never a suggestion that Photon should
be waiting for Quantum Render, or a WebRender subset of it. The
graphics team has been monitoring the Photon plans to see if something
surprising is coming up.

And there are no regressions with Quantum Render; the users that are not
qualified for the WebRender path in Quantum Render will get something
that's at worst as good as what they have today.

As far as the order of operations goes - I actually prefer what's
happening today, with Photon showing up before, or at the same time as
Quantum Render. Jack and I just happen to disagree on that point.


On 18-Apr-17 13:53, Justin Dolske wrote:

> On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt <ja...@metajack.im> wrote:
>
>>> Another really nice effort that is starting to unfold and I'm super
>> excited
>>> about is the new Photon performance project
>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>, which is a
>> focused
>>> effort on the front-end performance. This includes everything from
>>> engineering the new UI with things like animations running on the
>>> compositor in mind from the get-go, being laser focused on guaranteeing
>>> good performance on key UI interactions such as tab opening and closing,
>>> and lots of focused measurements and fixes to the browser front-end.
>> I think the order of operations here is unfortunate. What we'd prefer
>> is that WebRender land first, and then Photon be designed around what
>> is possible in the GPU-backed world.
>
> That's a complete non-starter. Photon work is already underway, and there's
> a _ton_ of work to do for the 57 release.
>

> Blocking Photon on another major project landing first would mean canceling
> Photon for 57.
>
> Justin
> _______________________________________________