1476241 - GMail UI is slow, check mails or scrolling usually happens after a delay in seconds

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect, P3)

Description

[brice.dutheil]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704003137

Steps to reproduce:

I have enabled the new GMail interface (2018), and I have a multi-inbox with ~100 mails, some read, some unread, mot mails are labelled.

Checking mails (as in toggling the checkbox), and scrolling around the hangout on the left, or the mails.

Firefox : 61.0.1 (64-bit)
OSX: 10.13.6 (17G65)
Hardware: MacBook Pro (Retina, 13-inch, Early 2015)

Here's the performance profile : https://perfht.ml/2zLQOdK


Actual results:

When checking mails with the mouse, the check mark appears seconds later. Scrolling usually lag as well.


Expected results:

Check marks should almost instantaneous, scrolling as well.

Comment 1

[brice.dutheil]

By the way I wonder if it matters, but the firefox window was placed on a vertical screen (1080 wide and 1920 high).

Comment 2

[Kanchan Kumari QA]

Hello Mike, can you please look into performance profiles here? Thanks!

Comment 3

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

I'm seeing some pretty long paint times in here. That's what stands out to me the most - handing over to Graphics for now.

Comment 4

[Sotaro Ikeda [:sotaro]]

(In reply to brice.dutheil from comment #0)
>
> Here's the performance profile : https://perfht.ml/2zLQOdK

Sometimes, ClientMultiTiledLayerBuffer::PaintThebes() took very long time.

:rhunt, can you comment to it? Might the problem already addressed on latest m-c?

Comment 5

[Ryan Hunt [:rhunt]]

I'm a bit confused by this profile. It looks like the main thread is doing skia rasterization, but we should have OMTP here.

Could you copy and paste your about:support here? Additionally, when profiling could you open settings and add 'Paint' to the list of threads?

Comment 6

[brice.dutheil]

Attachment: about:support

Here's the asked about:support info, if you want the raw text instead of the json, just ping me ;)

Comment 7

[brice.dutheil]

Here's the performance profile with the `Paint` thread (https://perfht.ml/2Ahabf0)

For this profile I used gmail in a regular monitor (non-retina) oriented horizontally, then I moved firefox window to an horizontally oriented (non-retina) monitor, then the GMail started to lag.

Comment 8

[brice.dutheil]

Also not sure that counts, but the laptop is plugged on the power supply.

Comment 9

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

ni?ing rhunt since the reporter has come back with the requested info.

Comment 10

[Stuart Philp :sphilp]

Anecdotally, turning off Hangouts (chat off in settings) helped quite a bit. I also noticed that it seems to perform better once the page has fully loaded (network requests end).

Comment 11

[Randell Jesup [:jesup] (needinfo me)]

How is this vertical monitor hooked up?  USB-C -> HDMI?  Does the same happen when using the built in screen, no external monitor connected?  (I.e. unplug from everything except power, or including power)

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

Also, I see 1password and ublock origin - can you disable them (or disable all extensions) and retry?  Just want to eliminate stuff that can slow things down, especially if you touched on a bug in the extension code

Comment 13

[Ryan Hunt [:rhunt]]

Apologies for the delay in looking at this profile. Long refresh ticks do seem to dominate this profile.

From focusing on `nsRefreshDriver::Tick` in the content process main thread, I see that display list building funcations are about 48% of the cumulative refresh ticks, layer building 10%, capturing for OMTP 9%. Script seems to be the remainder. Those are just estimates because each category has a long tail of 0% execution time functions that probably add to something together.

The paint thread times seem to be very insignificant here, and I don't see any blocking for async paints. It seems like display list building is taking the most time here.

I will also add that I do see some infrequent refresh ticks where 'rasterize' takes a very long time (>300ms). These seem to be caused by tile allocation and probably manifest as bad jank. Not sure if that's what the reporter is seeing. Bug 1477148 would improve this situation.

Comment 14

[brice.dutheil]

Sorry for the late reply.

(In reply to Stuart Philp :sphilp from comment #10)
> Anecdotally, turning off Hangouts (chat off in settings) helped quite a bit.
> I also noticed that it seems to perform better once the page has fully
> loaded (network requests end).

Agreed, removing hangout did help.

(In reply to Randell Jesup [:jesup] from comment #11)
> How is this vertical monitor hooked up?  USB-C -> HDMI?  Does the same
> happen when using the built in screen, no external monitor connected?  (I.e.
> unplug from everything except power, or including power)

My Macbook Pro 13" early 2015 does not have USB-C ;)
My setup is : two monitors, one plugged directly in the HDMI port, the other which is oriented vertically is plugged via the HDMI adapter - Thunderbolt 2.

With all my extensions disabled, no hangout, power plugged in, I moved the window on all screens, the retina, the vertical one and the other horizontal one. I noticed the slowness on the retina screen and the vertical one, but not that much on the horizontal external monitor.
With all my extensions disabled, no hangout, power plugged in, no external monitor, just the retina screen, I notice the same slowness when selecting a bunch of mails with my mouse.


(In reply to Randell Jesup [:jesup] from comment #12)
> Also, I see 1password and ublock origin - can you disable them (or disable
> all extensions) and retry?  Just want to eliminate stuff that can slow
> things down, especially if you touched on a bug in the extension code

Actually I'm not sure I can reproduce in the same situation, upon restart somewhat a week ago my Firefox updated to version 62.
Actually it doesn't help that much with these extensions disabled. There's still slowness.

Sometime I see one process 'FirefoxCP Web Content' jumping at ~120% of CPU usage (in Activity Monitor), when selecting a bunch of mails. (all extensions disabled, but hangout present).

Sorry no performance profile as I deactivated all my extensions.

Comment 15

[Karl Dubost💡 :karlcow]

Is this still happening?

Comment 16

[Gregory Pappas [:gregp]]

No response from the reporter in a year. Please comment or open a new bug if you are still experiencing this issue.