1427417 - Mouse hover on https://kangax.github.io/compat-table/esnext/ is atrociously slow

Status: RESOLVED FIXED

(Core :: Graphics, defect, P3)

Description

[Mayank Bansal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20171229220051

Steps to reproduce:

1. create new profile on nightly
2. Go to https://kangax.github.io/compat-table/esnext/
3. Move the mouse over the table/grid


Actual results:

extremely slow mouse-over effect on the table

Profile: https://perfht.ml/2EdIT77


Expected results:

fast.

Enabling Webrender makes the effects as fast as current chrome. We should try to be faster here.

Comment 1

[Mayank Bansal]

new profile : 
https://perfht.ml/2DbCOq0

Comment 2

[Mayank Bansal]

Attachment: aboutsupport.txt

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hi Mayank,

We analyzed this profile today during The Joy of Profiling Episode 21[1]. Here are our findings:

* The original profile was spending a lot of time waiting on the paint threads to finish up, but also didn't include the paint threads, which was a little problematic.
* Thankfully, we were able to reproduce the issue very easily, and produced new profiles on macOS and Windows, with and without WebRender.
  * Profile on Windows without WebRender: https://perfht.ml/2Hl16k4
  * Profile on Windows with WebRender: https://perfht.ml/2p2jV41
* WebRender does appear to make things better, but we think there might be more room for improvement here.
  * On the paint thread without WebRender, we appear to be waiting for D2D to finish thinking about things after we send stuff to it to draw. This might be related to filters, but we're not sure (we don't have a lot of visibility into what D2D is doing)
* Significant time seems to be spent inside nsFilterInstance::GetPreFilterNeededArea - specifically in the construction and destruction of nsFilterInstance's. This occurs not only during the display list construction phase, but also during layout and frame layer building (in the non-WebRender case).

So two things will improve this:

1) WebRender (already being worked on)
2) Optimizing nsFilterInstance::GetPreFilterNeededArea if possible

Hey mstange, I know you've already got a lot on your plate, but do you offhand know how much headroom there is for improving the efficiency of nsFilterInstance::GetPreFilterNeededArea?

[1]: https://air.mozilla.org/the-joy-of-profiling-episode-21/

Comment 4

[Markus Stange [:mstange]]

Bug 1417699 should help with this a bit. Once that's done, caching FilterDescriptions would be the next obvious step.
I'll see if I can find some time for bug 1417699...

Comment 5

[Mayank Bansal]

AS of the latest nightly which should have bug 1417699 fixed:

non-WR: https://perfht.ml/2PVqDod
WR: https://perfht.ml/2PSN2Cs

Comment 6

[Jeff Muizelaar [:jrmuizel]]

Is the WR performance now acceptable?

Comment 7

[Mayank Bansal]

I guess so. But then again, it was good enough before too.
I wouldnt mind calling this bug as RESOLVED FIXED BY WR, considering that one actionable item has been completed ( bug 1417699)

If its needed for WR, could you file a bug regarding the remaining work in comment 4 ? 
Thanks!

Comment 8

[Jeff Muizelaar [:jrmuizel]]

I'm not seeing much FilterDescription stuff show up in the WebRender profile so I don't see anything to file.

Comment 9

[Mayank Bansal]

here is a new profile with WR: https://perfht.ml/2R6uorM
large parts spent in JS

Comment 10

[Daniel Holbert [:dholbert]]

smaug noticed that, in a non-webrender scenario, we're spending lots of time in malloc/free for nsFilterInstance related things, as shown in this "invert call stack" view: https://perfht.ml/2Ddr9dH

Perhaps AutoTArray might help to preallocate & better-chunk some things? (Or arena allocation, or some other sort of allocation optimization?)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

FWIW, nsFilterInstance stuff is there also with webrender.

Comment 12

[Andrew Creskey [:acreskey]]

On the 2017 Reference Laptop (Windows 10), i3, the performance is noticeably poor (Nightly), with and without Webrender.
And also with the basic compositor (layers.acceleration.disabled = true).
I'll attach a profile.

Comment 13

[Andrew Creskey [:acreskey]]

From Nightly 66.0
https://perfht.ml/2SWvkA6

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

(the malloc heaviness isn't fixed by webrender.)