1242861 - Google Inbox slow and cpu intensive

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Daniele Dellafiore]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160125060632

Steps to reproduce:

1. Open Firefox Nightly (fresh empty profile)
2. Open https://inbox.google.com (already logged in)



Actual results:

Clock on hand: 
Almost immediately, the page renders but is non-reactive to click/scroll and Firefox continues to load. 
After 15 seconds, Firefox show the message "a web site is slowing firefox down: Stop / Wait". I click on Wait. 
After 30 seconds, Firefox stop loading and page is complete. 


Expected results:

Facebook is completely rendered and usable in 5 seconds, that include of course network overhead. I expect Inbox to be available in a comparable amount of time. Also, the Firefox Warning should mean something. 

I followed the instructions here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Here is Cleopatra report: https://cleopatra.io/#report=1854b441a8e1d6922752bc792903661ce65577dc

Comment 1

[Daniele Dellafiore]

In general, all Google products have really terrible startup performances, Inbox takes almost 10 seconds on Chrome as well. But 30s is a lot more. I can easily believe that is an Inbox fault... still. Please let me know if I need to run some different test or how can I help in other ways. Thanks.

Comment 2

[Daniele Dellafiore]

System details (there's no specific place to write this so I'll just add a comment)

Dell XPS 13 L322X
Intel® Core™ i7-3537U CPU @ 2.00GHz × 4. 
Ubuntu 15.10
Linux 4.2.0-25-generic #30-Ubuntu SMP x86_64

Comment 3

[Brindusa Tot, Desktop QA]

Daniele, could not reproduce this with new profile on
 -  Nightly 47.0a1, Build ID: 20160131030347, User Agent Mozilla/5.0 (X11; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0.


Could you please try and see whether this issue occurs using Firefox in safe mode?

http://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 4

[Brindusa Tot, Desktop QA]

Chris, could you please take a look at the Cleopatra report linked in bug description (https://cleopatra.io/#report=1854b441a8e1d6922752bc792903661ce65577dc) and see if you can help?

Comment 5

[Daniele Dellafiore]

Hi. I cannot reproduce myself now, it lasted for a few days both on stable FF43 and on the Nightly with fresh profile + no addons, the latter I used for the cleopatra report. 
Now it loads "only" for 10 seconds :)

Comment 6

[Chris Peterson [:cpeterson]]

Daniele, thanks for the Cleopatra report! That can make debugging the performance problem much easier.

Unfortunately, I'm not the right person to review these Cleopatra profiler reports. If we knew whether this was a JavaScript or layout performance issue, I could recommend someone, but I'm not sure who the right person would be to triage new performance bugs.

Comment 7

[Andrew McCreight [:mccr8]]

I don't see any indication that this is memory-related, so I'm removing the MemShrink tag.

Comment 8

[Daniele Dellafiore]

The general issue is that Inbox loading is really CPU intensive on Firefox, compared also to other non-trivial HTML pages. So intense that takes 10 seconds in which the CPU is almost always 100% usage and other screen trask are slowed down, like opening a new tab has some serious lag. 
This does not happen on Chrome on the same machines I am experiencing this on Firefox (one Ubuntu and one Windows). 
I do not think this is happening just to me and for sure this is also an Inbox issue. Still, Chrome loads it quicker and without slowing down the UI for other tasks.

Comment 9

[Daniele Dellafiore]

as I am experiencing this on 2 computers, an Ubuntu and a Windows, do you feel Inbox and other google products load smoothly or have a significant delay at startup that also hangs the Firefox UI for a significant while? 

Can I provide some more evidence other than a Cleopatra report?

Comment 10

[developer]

I can confirm that with "javascript.options.baselinejit" set to "false" it becomes really slow to the point that the "slow script" dialog pops up.  However, for the most part it's loading ok though it has a slight "laggy" feel.

Comment 11

[Brindusa Tot, Desktop QA]

Benoit, could you, please, help us with the Cleopatra report? Can you see any clue in it which might help understanding what causes the issue?

Comment 12

[Benoit Girard (:BenWa)]

This profile is showing a session that is not running well at all and is consistent with the bug description:
- I see 200ms of google hangout execution (likely unrelated)
- Most of the execution time is indeed coming from Google Inbox. It's responsible for large blocks of 300ms of continuous execution.
- There some notable time spent in our GC code and in Google Indox causing a sync restyle+reflow.

The Inbox script are minified so I can't really tell what it's doing and why it's so slow.

I can't tell from the profile if 1) The script is running slow because it's doing too much or 2) The JIT is running optimizing the code well. If the performance is significantly worse in Firefox than other browsers with the same workload we could maybe ping the JS team to take a look.

Comment 13

[laurens]

I've had the same problem across 3 Macs, since FF version 23 for the past couple of years
Google.com and Firefox gives 30% CPU on idle
https://bugzilla.mozilla.org/show_bug.cgi?id=877597

I've reset my profile, safe mode etc - doesn't make a difference.
I'm on laptop a lot - so 30-40% CPU for showing an idle search results page is a lot.

Comment 14

[Peleg]

Same problem here with Firefox 46.0, running on Ubuntu 14.04.4 LTS, 64bit.

Even When I'm already inside google inbox, and I'm refreshing or trying to expand a bundle, my cpu jumps to way above 100% for a couple of seconds, and the loading wheel on the tab is not rolling continuously.

When I'm doing so, `compiz` also jumps to 10-20% cpu usage. Can it be somehow related?

Comment 15

[Mary S.]

I have been experiencing the same problems ever since I started using Inbox (appx. 6 months ago). 

Firefox 46.0.1, running on Windows 10 64bit

Comment 16

[Brindusa Tot, Desktop QA]

Jan, when time permits, could you please take a look over this?

Comment 17

[Jan de Mooij [:jandem]]

Sorry for the delay. Is anyone still able to reproduce this with Firefox 47 or Nightly?

On Mac (Nightly and Firefox 47) with a clean profile, Google Inbox is usable after at most 5 seconds...

Comment 18

[Jan de Mooij [:jandem]]

Hannes can you try to reproduce this? It doesn't repro for me (comment 17).

Comment 19

[jon.reeve]

I am definitely seeing very slow Google Inbox speeds with FF 48 on Linux. When it first starts up, everything is extremely slow. Clicking on a category like "Updates," for instance, shows a loading bar for upwards of 20 seconds before it shows the category itself. Individual emails can take around the same amount of time to load. The same action in Chromium is instantaneous. Once the tab has been open a little while, though, it speeds up a bit.

Comment 20

[Baraa]

Same issue here with Firefox 48.0.1 Mac or Windows, the regular GMail is really fast, but https://inbox.google.com has really a slow (15+ sec) startup

Comment 21

[Mark Kim [:markhkim]]

Same issue here with Nightly 52.0a1 (2016-09-21) on Linux Mint 18. Inbox starts out fine, and then within a few minutes it crashes the entire browser.

Comment 22

[iakov.davydov+mozsync]

I can confirm that inbox is still slow in nightly: 54.0a1 (2017-02-13) (64-bit), Ubuntu Linux 16.04.1.
Especially actions like opening an email.
https://cleopatra.io/#report=1d06cacf93bd9379022be74d96600ce09bbf3828

Comment 23

[isaac.nic]

Same experience on Firefox Dev Edition 55.0b3 (64-bit).

Comment 24

[Matt Koidin]

I'm having this issue on the latest Nightly (56.0a1 (2017-07-05) running on Mac 10.12.5.

Very slow to load and individual email thread I click take a long time to load as well. I also got some browser crashes (which I submitted) when trying to attach files to emails.

Happy to provide more information if you point me in the right direction.

Comment 25

[diegofcviegas]

Starting some days ago, FF 52.2.0 (64-bit) running on Linux Debian 8 is using most of CPU time when browsing Gmail. The computer didn't have any special modification those days. Monitoring about:performance, it's clear that the problem is related to Gmail tabs. If I try the same work stuff, opening Gmail on Chrome, no problems. But sure, I want to keep using FF as main and only browser if possible.

Thanks.

Comment 26

[Samael Wang [:freesamael] (away for now)]

I got one specific slow profile on macOS. I'm seeing a lot of GCs.

https://perf-html.io/public/f4982ae1ff216a118513cb91332e637e2ff82da5/calltree/?hiddenThreads=&search=inbox&thread=4&threadOrder=0-2-3-4-5-1

Comment 27

[Stefan Fleiter (:sfleiter)]

I have not seen these extra long GC issues since bug 1374797 landed.

Comment 28

[Wayne Mery (:wsmwk)]

(In reply to Stefan Fleiter (:sfleiter) from comment #27)
> I have not seen these extra long GC issues since bug 1374797 landed.

Does anyone disagree?

Comment 29

[Worcester12345]

"WORKSFORME"?

Comment 30

[completej]

Gmail has become more or less unusable for me over the last few months on Firefox, on both win7 55.0.2 and macOS.  (As an aside, FF on mac consumes battery power at almost nearly the rate of chrome as well.)

Comment 31

[thekswenson]

I currently experience mediocre load times but very poor message thread opening times for inbox using FF 55.0.2 (Ubuntu 17.04).  There are also BUGS when using inbox in FF that do not exist in Chrome.  This may be what @completej is referring to when she says "unusable".

Comment 32

[minh.haduong]

FF 56.0 (64 bits) on Ubuntu 17.04. Same here, very poor message thread opening times for inbox. Looks like a deliberate anticompetitive move.

Comment 33

[jason]

With the release of FF57, I see Inbox really harming my performance.  I was able to get a perf-html.io created:


https://perfht.ml/2zHzk0J

Comment 34

[thekswenson]

Inbox is very responsive now (and seems to work correctly) on FF57 at least.

Comment 35

[Samael Wang [:freesamael] (away for now)]

I got a slow profile on macOS, with Nightly build 20180103230158. js::RunScript took ~4.1s to finish: https://perfht.ml/2AtUYC9

Comment 36

[Drew]

I am also experiencing this problem, to the extent that google inbox is unusable.

MacOS 10.13.2 (17C88)
FF 57.0.3 (64-bit)

Comment 37

[seb.bacon]

I am also experiencing this (or a similar) problem.

My specific issue is that, when using Inbox, sometimes it is impossible to unfold a thread. I cannot reliably reproduce, but when it happens it happens for 10 minutes or so before recovering.  It never happens when using Chromium.

https://perfht.ml/2DJz2GB

Comment 38

[Luis Rodrigues]

(In reply to seb.bacon from comment #37)
> I am also experiencing this (or a similar) problem.
> 
> My specific issue is that, when using Inbox, sometimes it is impossible to
> unfold a thread. I cannot reliably reproduce, but when it happens it happens
> for 10 minutes or so before recovering.  It never happens when using
> Chromium.
> 
> https://perfht.ml/2DJz2GB

I'm experiencing exactly the same symptoms.
Super slow unfolding a thread.

Comment 39

[derek.hansell]

I am also having this problem. It doesn't ever hose up my whole Fx instance, but the performance is dramatically worse.

Window 10 Pro 1709 Build 16299.371
Firefox 59.0.3 (64-bit)

Comment 40

[derek.hansell]

(In reply to derek.hansell from comment #39)
> I am also having this problem. It doesn't ever hose up my whole Fx instance,
> but the performance is dramatically worse.
> 
> Window 10 Pro 1709 Build 16299.371
> Firefox 59.0.3 (64-bit)

https://perfht.ml/2FzWTrx

Comment 41

[Chris Peterson [:cpeterson]]

Tagging [qf] for Quantum Flow triage

Comment 42

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

Hey jandem,

This last profile shows a massive amount of time being spent inside CC of CacheIR stubs:

https://perfht.ml/2wohobn

Any insight?

Comment 43

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

(Where a lot of time is like 10s)

Comment 44

[Jan de Mooij [:jandem]]

(In reply to Mike Conley (:mconley) (:⚙️) (PTO - back May 7) from comment #42)
> This last profile shows a massive amount of time being spent inside CC of
> CacheIR stubs:

Hm we have a huge CC slice of 10 seconds here. This reminds me of bug 1449033 and maybe bug 1452177.

mccr8, WDYT?

Comment 45

[Jan de Mooij [:jandem]]

It's true we spend quite a lot of time under BaselineScript::Trace in that profile. Is it possible we're tracing the JS runtime many times or is this a single trace? In the latter case there must be some huge scripts. Also even without the BaselineScript::Trace time I think this CC would be pretty slow.

Comment 46

[Andrew McCreight [:mccr8]]

Yeah, it does look similar to bug 1449033. The CC can end up repeatedly tracing an object that returns false for AddToCCKind if it is held onto by an object that is of CC kind. If there are multiple of these in a chain, then this can cause an exponential blowup in the CC tracing. Maybe there's some problem like this for the JIT stubs. I do see JS::GCCellPtr::mayBeOwnedByOtherRuntimeSlow() in there, taking up 18% of the time, like bug 1449033.

Comment 47

[Jan de Mooij [:jandem]]

(In reply to Andrew McCreight [:mccr8] from comment #46)
> The CC can end up repeatedly
> tracing an object that returns false for AddToCCKind if it is held onto by
> an object that is of CC kind.

Hm interesting - I think we have that situation here because we're tracing JSScript (CC kind) -> BaselineScript -> IC stubs -> Shape* (not CC kind).

Comment 48

[Jan de Mooij [:jandem]]

I was confused why we ended up in mayBeOwnedByOtherRuntimeSlow under TraversalTracer::onChild when tracing strings, because it has a fast path to avoid that [0]. However it turns out that fast path was added a few months ago by bug 1447391. So that part should be much better in 61+.

[0] https://searchfox.org/mozilla-central/rev/5ff2d7683078c96e4b11b8a13674daded935aa44/xpcom/base/CycleCollectedJSRuntime.cpp#410

Comment 49

[Worcester12345]

You know, I am just noticing this bug again. Recently, I was at a library, and checked my Yahoo email with Chrome browser. WOW! What a difference. I then tried it at home, and it was LIGHT YEARS ahead of Firefox in terms of speed. Is there a similar bug to this one, or is it the same bug, for Yahoo Mail? Thanks.

Comment 50

[Andrew McCreight [:mccr8]]

(In reply to Worcester12345 from comment #49)
> You know, I am just noticing this bug again. Recently, I was at a library,
> and checked my Yahoo email with Chrome browser. WOW! What a difference. I
> then tried it at home, and it was LIGHT YEARS ahead of Firefox in terms of
> speed. Is there a similar bug to this one, or is it the same bug, for Yahoo
> Mail? Thanks.

It is impossible to know if this is the same issue without further investigation, so please file a new bug. In the worst case, it will end up being the same thing and we can merge that issue into this one.

Comment 51

[Vicky Chin [:vchin]]

(In reply to Jan de Mooij [:jandem] from comment #48)
> I was confused why we ended up in mayBeOwnedByOtherRuntimeSlow under
> TraversalTracer::onChild when tracing strings, because it has a fast path to
> avoid that [0]. However it turns out that fast path was added a few months
> ago by bug 1447391. So that part should be much better in 61+.
> 
> [0]
> https://searchfox.org/mozilla-central/rev/
> 5ff2d7683078c96e4b11b8a13674daded935aa44/xpcom/base/CycleCollectedJSRuntime.
> cpp#410

Are we still seeing this issue or have the fixes in fx61 resolved this? I just tried on my machine (MacOS) using nightly and Google Inbox loads pretty fast.

Comment 52

[isaac.nic]

(In reply to Vicky Chin [:vchin] from comment #51)
> (In reply to Jan de Mooij [:jandem] from comment #48)
> > I was confused why we ended up in mayBeOwnedByOtherRuntimeSlow under
> > TraversalTracer::onChild when tracing strings, because it has a fast path to
> > avoid that [0]. However it turns out that fast path was added a few months
> > ago by bug 1447391. So that part should be much better in 61+.
> > 
> > [0]
> > https://searchfox.org/mozilla-central/rev/
> > 5ff2d7683078c96e4b11b8a13674daded935aa44/xpcom/base/CycleCollectedJSRuntime.
> > cpp#410
> 
> Are we still seeing this issue or have the fixes in fx61 resolved this? I
> just tried on my machine (MacOS) using nightly and Google Inbox loads pretty
> fast.

My experience has improved a lot on recent updates since a year ago when I reported it being slow.

Firefox Dev Edition 62.0b5 (64-bit) on macOS.

Comment 53

[Baraa]

No noticeable improvement. Inbox still not really usable, loading the inbox itself takes a lot of time, and opening a thread is just as bad. nowadays I use another browsers to check my emails!

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

Comment 54

[Drew]

for me, it's a little better than it was, but it still often freezes and crashes FF. I never have the problem if inbox is not open in a tab.

Comment 55

[Andrew Overholt [:overholt]]

(In reply to Baraa from comment #53)
> No noticeable improvement. Inbox still not really usable, loading the inbox
> itself takes a lot of time, and opening a thread is just as bad. nowadays I
> use another browsers to check my emails!

Is it possible for you to attach a profile of the situation? Links to install the extension and documentation are available at https://perf-html.io/.

Comment 56

[Baraa]

(In reply to Andrew Overholt [:overholt] from comment #55)
> (In reply to Baraa from comment #53)
> > No noticeable improvement. Inbox still not really usable, loading the inbox
> > itself takes a lot of time, and opening a thread is just as bad. nowadays I
> > use another browsers to check my emails!
> 
> Is it possible for you to attach a profile of the situation? Links to
> install the extension and documentation are available at
> https://perf-html.io/.

Of course, here you go! https://perfht.ml/2mrx0TH

Comment 57

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

Hi Baraa,

If you disable LastPass and restart the browser, do things improve?

Comment 58

[Baraa]

(In reply to Mike Conley (:mconley) (:⚙️) (PTO Jul 24th-Aug 6th)) from comment #57)
> Hi Baraa,
> 
> If you disable LastPass and restart the browser, do things improve?

Hi Mike,

Not at all ... https://perfht.ml/2uGnNKG

Comment 59

[Ben Limmer]

I'm experiencing this with Firefox 62.0b15 . Consistently experiencing load times of over 1 minute. This trace shows that it took almost 90s to load. Walltime on Chrome is < 3 seconds.

https://perfht.ml/2KFMwoq

Comment 60

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

The profile in comment 59 is pretty incredible - we're stuck running script for at least 50s.

Comment 61

[Ben Limmer]

I can pretty consistently reproduce that behavior when first launching the browser and visiting inbox.google.com . Subsequent reloads are slightly better, but still significantly longer than Chrome. Happy to do additional debugging if that'd be helpful.

Comment 62

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

Hey djvj, check out Ben's profile here in comment 59. Anything from that big script run jump out at you?

Comment 63

[Worcester12345]

Anybody else seeing perfomance issues in Yahoo mail also?

Comment 64

[Wayne Mery (:wsmwk)]

Danielle reported to me "April 2018 the loading is kind of slow but most
importantly, even after load is complete, firefox Web Content process
is always ~100% cpu. If I close the Inbox ta, goes back to norma ~10%."

Comment 65

[Stephen Donner [:stephend] Not actively reading bugmail]

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

Comment 66

[u597032]

Inbox no longer existing