1100340 - e10s - Performance is significantly slower on 32bit Linux machines

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, defect)

Description

[Paul [pwd]]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141115210040

Steps to reproduce:

Sorry for how non-technical this bug is, but I'm not sure how best to describe it other than performance is incredibly slow for 32 bit Linux machines. Considerably slower than a non e10s page load. After some discussion on MozilliaZine, it would appear the problem doesn't affect 64 bit machines.

Comment 1

[:Gijs (out for now; he/him)]

(In reply to Paul [pwd] from comment #0)
> User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:36.0) Gecko/20100101
> Firefox/36.0
> Build ID: 20141115210040
> 
> Steps to reproduce:
> 
> Sorry for how non-technical this bug is, but I'm not sure how best to
> describe it other than performance is incredibly slow for 32 bit Linux
> machines. Considerably slower than a non e10s page load. After some
> discussion on MozilliaZine, it would appear the problem doesn't affect 64
> bit machines.

Can you link to this discussion? Can you provide measurements on the same machine for 32 and 64-bit builds? Are you sure this isn't just about how the 64-bit machines are more likely to be recent than the 32-bit machines?

Comment 2

[Liz Henry (:lizzard) (relman/hg->git project)]

Here's the discussion: http://forums.mozillazine.org/viewtopic.php?f=23&t=2779793&p=13879859

Comment 3

[Paul [pwd]]

(In reply to :Gijs Kruitbosch from comment #1)
> (In reply to Paul [pwd] from comment #0)
> > User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:36.0) Gecko/20100101
> > Firefox/36.0
> > Build ID: 20141115210040
> > 
> > Steps to reproduce:
> > 
> > Sorry for how non-technical this bug is, but I'm not sure how best to
> > describe it other than performance is incredibly slow for 32 bit Linux
> > machines. Considerably slower than a non e10s page load. After some
> > discussion on MozilliaZine, it would appear the problem doesn't affect 64
> > bit machines.
> 
> Can you link to this discussion? Can you provide measurements on the same
> machine for 32 and 64-bit builds? Are you sure this isn't just about how the
> 64-bit machines are more likely to be recent than the 32-bit machines?

I don't have measurements, it was a non-technical discussion. But if there's a build or tool to measure just how bad performance is effected with e10s enabled, I'd be happy to provide the data required.

Comment 4

[:Gijs (out for now; he/him)]

(In reply to Paul [pwd] from comment #3)
> (In reply to :Gijs Kruitbosch from comment #1)
> > (In reply to Paul [pwd] from comment #0)
> > > User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:36.0) Gecko/20100101
> > > Firefox/36.0
> > > Build ID: 20141115210040
> > > 
> > > Steps to reproduce:
> > > 
> > > Sorry for how non-technical this bug is, but I'm not sure how best to
> > > describe it other than performance is incredibly slow for 32 bit Linux
> > > machines. Considerably slower than a non e10s page load. After some
> > > discussion on MozilliaZine, it would appear the problem doesn't affect 64
> > > bit machines.
> > 
> > Can you link to this discussion? Can you provide measurements on the same
> > machine for 32 and 64-bit builds? Are you sure this isn't just about how the
> > 64-bit machines are more likely to be recent than the 32-bit machines?
> 
> I don't have measurements, it was a non-technical discussion. But if there's
> a build or tool to measure just how bad performance is effected with e10s
> enabled, I'd be happy to provide the data required.

Running any kind of benchmark about web performance would be helpful. If there are things that stand out, using the gecko profiler ( https://github.com/bgirard/Gecko-Profiler-Addon ) may help.

Comment 5

[Paul [pwd]]

Attachment: e10s_profiles.zip

(In reply to :Gijs Kruitbosch from comment #4)
> (In reply to Paul [pwd] from comment #3)
> > (In reply to :Gijs Kruitbosch from comment #1)
> > > (In reply to Paul [pwd] from comment #0)
> > > > User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:36.0) Gecko/20100101
> > > > Firefox/36.0
> > > > Build ID: 20141115210040
> > > > 
> > > > Steps to reproduce:
> > > > 
> > > > Sorry for how non-technical this bug is, but I'm not sure how best to
> > > > describe it other than performance is incredibly slow for 32 bit Linux
> > > > machines. Considerably slower than a non e10s page load. After some
> > > > discussion on MozilliaZine, it would appear the problem doesn't affect 64
> > > > bit machines.
> > > 
> > > Can you link to this discussion? Can you provide measurements on the same
> > > machine for 32 and 64-bit builds? Are you sure this isn't just about how the
> > > 64-bit machines are more likely to be recent than the 32-bit machines?
> > 
> > I don't have measurements, it was a non-technical discussion. But if there's
> > a build or tool to measure just how bad performance is effected with e10s
> > enabled, I'd be happy to provide the data required.
> 
> Running any kind of benchmark about web performance would be helpful. If
> there are things that stand out, using the gecko profiler (
> https://github.com/bgirard/Gecko-Profiler-Addon ) may help.

Hopefully these help.

Comment 6

[Paul [pwd]]

So I was hoping much of this would be down to perception as a result of bug 1106936 but it turns out that's not the case. Rendering is still far far slower than with e10s disables (i.e. a blank white screen is displayed). Still getting a giant spinner on dormant tabs. On opening Firefox, it still takes a very long time to load app tabs. Some of the performance issues are best showcased when comparing opening a bookmarks folder (say 8 tabs).

Comment 7

[msth67]

I haven't done any profiling yet,just some basic tests enabling OMTC along with e10s in Linux 64bit, and there is detectable hit in performance here too : in other words, as far as I can see e10s  is significantly slower on Linux 64bit as well.

Comment 8

[Paul [pwd]]

I believe bug 1066531 could significantly help in regards to this issue.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

Lots of changes in the last yea, still see this?

Comment 10

[Ben Bucksch (:BenB)]

Just a data point: I'm using Linux 64bit (Ubuntu 12.04 on an AMD 4 core CPU), and enabled e10s in my nightly builds in summer 2015 for my main browser, and I also found it so incredibly slow that it impaired my work, to the point that I was so frustrated at my browser that I wanted to throw it out of the window and use Chrome (despite being Mozilla developer since 15 years). Then, I remembered that I had e10s on, and tweaked the process count to many, then down to 1, but the effect was still there. Then I disabled e10s and it was (mostly) back to normal.

Primary problem was that the browser would take pauses (I think it was for JS GC), completely halt and not take any input for 2-10 seconds, then resume. And do that often.

Instead of increasing responsiveness, e10s completely destroyed it to the point that I wanted to give up on Firefox.

I haven't tried in the last months. Either way, this is a must-fix before release, otherwise users will leave in droves to Chrome.

Comment 11

[:Gijs (out for now; he/him)]

(In reply to Ben Bucksch (:BenB) from comment #10)
> Just a data point: I'm using Linux 64bit

This bug is about 32-bit Linux.

> I haven't tried in the last months.

Then your input here is even less relevant. A lot of performance work was done in the last few months. Try it again and, if you see the same kind of issue, file a new bug with more details, especially profiles as Paul did here. Don't clutter up other existing bugreports with irrelevant comments - which, after 15 years of being a Mozilla developer, you should know not to do. Be constructive.

Comment 12

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

Looking at these profiles, a ton of time is being spent in AdBlock and NoScript over the shims.

I know that both of these add-ons have gotten a lot better at avoiding shims with their latest updates. Reporter, are you still seeing this slowdown?

Comment 13

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

Going to close this out until we get profiles showing slowdowns in core code.