1263206 - Long layout/rendering times on site when compared to other browsers

Status: NEW

(Core :: Layout, defect)

Description

[Justin]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

Steps to reproduce:

1. Visit https://console.developers.google.com/ and go to the Logs viewer. 
2. Try to interact with the page, i.e. clicking on log rows, type in the filter bar, etc.


Actual results:

Interaction with the page is very sluggish, upwards of seconds of delay when clicking on elements in the page, typing text into the filter bar has 10's - 100's MS delay between keystrokes. After a quick profile in the developer tools I notice a large portion of the time, several seconds, is spent in layout.


Expected results:

Interaction with the page should not be sluggish. I tested a few other browsers and the page did not exhibit the same behavior.

Comment 1

[Justin]

Note that I am one of the engineers at Google that works on the logs viewer. I've spent a good bit of time trying to track down the root cause of the issue but haven't been able to gain any significant traction.

When I created the bug it injected my user agent. Here is the user agent of the browser that I am actually experiencing the issues on: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

Note that I've also tried in a few other versions of Firefox and am experiencing the same issue. To date I've tried Firefox 43, 44, 45, and the developers edition, 47.0a2.

Comment 2

[Timothy Nikkel (:tnikkel)]

How do I get to the Logs viewer? I couldn't see it anywhere. Do I need to sign up and provide a credit card?

Comment 3

[Justin]

Hi Timothy, I've added you as a viewer to a demo project. You should have access at https://console.cloud.google.com/logs?project=burnished-mark-846. Let me know if you have any issues.

Comment 4

[Timothy Nikkel (:tnikkel)]

Hmm, this is odd. On mac things are reasonably quick. On Windows typing in the filter box is slow. On linux typing in the filter box and clicking on an entry to open it is slow.

Comment 5

[Timothy Nikkel (:tnikkel)]

This is something we should probably put on our radar.

Comment 6

[Jet Villegas (inactive)]

(In reply to Timothy Nikkel (:tnikkel) from comment #5)
> This is something we should probably put on our radar.

It's odd that this is platform-specifc, maybe font-lookup related? Jonathan, can you pull a profile and post up your findings? Thx!

Comment 7

[Jonathan Kew [:jfkthame]]

(In reply to Justin from comment #3)
> Hi Timothy, I've added you as a viewer to a demo project. You should have
> access at https://console.cloud.google.com/logs?project=burnished-mark-846.
> Let me know if you have any issues.

Justin, can you give me access to this as well? Currently, I don't think I have any way to test/profile this and try to see what's going on...

Comment 8

[Justin]

Done, your should have access now Jonathan, let me know if you need anything else.

Comment 9

[Jonathan Kew [:jfkthame]]

Thanks, Justin.

And the result is...

(In reply to Timothy Nikkel (:tnikkel) from comment #4)
> Hmm, this is odd. On mac things are reasonably quick. On Windows typing in
> the filter box is slow. On linux typing in the filter box and clicking on an
> entry to open it is slow.

...that I don't think I'm seeing the same platform-dependent behavior here. I tried on both Windows and Linux, and clicking an entry to open it seems pretty responsive to me.

Typing in the filter box does have some lagginess (on all platforms, including Mac OS X as well), which seems to be mainly related to a keyUp handler that's taking in the region of 70-90ms. Most of that appears (if I'm understanding the profiler correctly) to be spent in layout that's occurring from within the keyUp handler. It looks like every keystroke in the filter box triggers a reflow of the entire page's frame tree, which seems unfortunate; I don't think it's normal behavior when typing in an input field on other pages. But I don't know what the keyUp handler is doing that would trigger this...

Just as a wild guess, perhaps it's related to the auto-suggestions panel (the <pan-chip-auto-suggest> element & friends) that the page is using; that must be getting dynamically updated as you type. It looks like that has 'position: absolute', so it seems like changes to it shouldn't affect the rest of the page, but perhaps we don't optimize that adequately?

(I also tried loading the log-viewer in Safari, and typing definitely felt snappier there, so it seems like there ought to be room for improvement.)

Comment 10

[Timothy Nikkel (:tnikkel)]

(In reply to Jonathan Kew (:jfkthame) from comment #9)
> Just as a wild guess, perhaps it's related to the auto-suggestions panel
> (the <pan-chip-auto-suggest> element & friends) that the page is using; that
> must be getting dynamically updated as you type. It looks like that has
> 'position: absolute', so it seems like changes to it shouldn't affect the
> rest of the page, but perhaps we don't optimize that adequately?

Hmm, we don't even call RestyleManager::RecomputePosition in this case, so the "avoid reflow and just move" optimization isn't even attempted, it must be pre-empted somewhere before that.

Comment 11

[Justin]

Just wanted to check in and see if there were any updates on this? 

Also, if there is any other information that you need from me, just let me know. I'm glad to help in any way I can! Here are some additional observations (using FF dev 48.0a2 on Ubuntu).

On filtering:
- The filter bar uses contenteditable elements for input, could this be impacting performance?
- There seems to be an extended delay during focus/blur in the filter bar. I'm experiencing ~500-600ms time on focus event. Blur is taking ~1500ms. At least with the focus of the filter bar it seems to be related to an explicit focus event that is fired to ensure the contenteditable element gets the proper focus when clicking in the filter bar element. On older versions of Firefox these numbers can easily double.
- I tried removing the pan-chip-auto-suggest, this helped but not by much.
- I noticed that if I turn on pain highlighting that when I type in the filter bar there are some elements in the log row that also get repainted, not sure why this is happens or how to prevent it, it seems like those elements should not be impacted by typing in the filter bar.

In general UI is slow, some examples:
- Opening/closing the left main navigation takes 1+ seconds.
- Opening and interacting with log elements is slow, elements that open a menu take ~300+ms before the menu is visible.
- Hovering over a log rows tends to trail behind the cursor (hover is triggered using CSS :hover).

Comment 12

[Justin]

I've revisited this issue with Firefox 47 and it appears to have improved significantly with Firefox on Mac, with only a minimal delay when typing in the filter bar. Interacting with the page has acceptable performance. 

This is not the case with Firefox 47 on Linux. It still has most of the performance issues outlined in my last comment 11.