Closed Bug 1322441 Opened 7 years ago Closed 6 years ago

The Internet Download Manager add-on can seriously slow down Firefox with e10s

Categories

(Firefox :: Extension Compatibility, defect)

50 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: andy, Unassigned, NeedInfo)

References

(Blocks 1 open bug)

Details

(Keywords: perf)

Attachments

(1 file)

29.67 KB, application/x-xpinstall
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161129173726

Steps to reproduce:

Installs with e10s enabled are horrifically slow. I have multiple machines running identical, local hosted web apps on identically hardware spec'd machines. In instances where FF chooses to enable e10s, CPU usage is 2x worse and memory is 10x worse. This is not ideal. To add insult to injury, the system mis-reports the cause of the problem.


Actual results:

Poor performing instances have e10s enabled. CPU is roughly 2x worse and RAM usage is roughly 10x worse than instances of the same FF version where e10s is not enabled. All badly performing instances show plugin-container.exe as the problem and disabling plugins does nothing to resolve the situation. Setting all plugins to "Never Activate" does nothing to plugin-container.exe resource usage.


Expected results:

Setting plugins to "Never Activate" should always solve problems with Firefox's "plugin-container.exe" causing resource problems. Instead disabling e10s completely reliably solves these performance problems.

Behavior related to separating per-tab processes, which has *literally nothing* to do with plugins, should not be reliant of a process name plugin-continer.exe. This is misleading on more than one level.
The e10s container process has been changed to firefox.exe in Fx50 and above, by bug 1114647.
Blocks: e10s-perf
Component: Untriaged → Tabbed Browser
Keywords: perf
me too. My pc has 2 core cpu. when Firefox e10s is enabled, instead of make performance 2x, made performance -2x. e10s system is bad.
I am in the same boat.  With e10s turned on, the performance was absolutely awful.  I first noticed it in a VM that only had a single CPU core, and I would typically see the CPU usage pegged at close to 100% all of the time.  But I started looking at non-VMs, and I was noticing heavy CPU usage there as well.  This is even while the browser is idle.

It took a while to track down - it wasn't obvious as to whether the problem was caused by Windows Update, something wrong with VirtualBox, or something else.  I had tried safe mode, I tried attaching a debugger (and loading Mozilla debug symbols) - it didn't tell me much other than the fact that it was somewhere in xul.  I had tried creating a new profile - even what I would characterize as an idle browser with just one tab at the firefox welcome page pegged the CPU at high levels.

Performance was so bad that I avoided using Firefox on that machine - it was just too much aggravation.  Pages would take forever to load - trying to switch from one tab to another easily resulted in a 10 second (or more) lag before the browser responded.

And finally I remembered that the e10 thing was pushed out (seeing multiple firefox.exe in the task manager was the clue I needed).  I turned off multiple processes, and CPU usage dropped back to minimal CPU usage and the browser is again responsive as before.

In my case it is version 50.1.0 that I am running.
when e10s is enabled, in Facebook.com performance of Firefox is bad. when i move the mouse over like and click, this action occurs after few seconds, for every like. but if e10s be disabled, like-ing process will be done fast, for every like.
If you can reproduce the performance issues mentioned, can you please help us diagnose why the performance is bad?  It's very easy to do and won't take more than a few minutes.  Here is how:

1. Please go to https://perf-html.io/ and click on the link to download the "gecko profiler addon".
2. Once the add-on is installed (doesn't need a restart) you should see the icon in the toolbar similar to the screenshot.
3. Make sure the profiler is running (the icon should be blue when the profiler is active) and when you are experiencing bad performance, please press Ctrl+Shift+2.  A new tab would be opened where the information about the profile is displayed.
4. Wait for the "Waiting for ..." message displayed at the top of the page to go away.
5. Click on the green "Share..." button at the top to upload your profile.  Once the upload is finished you should get a URL like https://perfht.ml/2lNEKzW.  Please provide this URL here.

Different performance issues may have different underlying causes, even though they may appear to have very similar symptoms, so if you experience performance issues on different websites it may be a good idea to upload and share a few of these profiles.  The more the better.  :-)  I'd be happy to take a look at them to try to figure out the root cause so that we can fix it.

Thanks a lot!
When i click on Upload profile, show this error:
An error occurred during upload:

xhr onerror was called, xhr.statusText:
upload problem fixed by using vpn. the link: https://perfht.ml/2kVywPD
(In reply to Saad Shamsaee from comment #7)
> upload problem fixed by using vpn. the link: https://perfht.ml/2kVywPD

Thanks a lot for helping with this, Saad!

This profile shows that almost all of the time on the parent process main thread is spent servicing an add-on called "Internet Download Manager".  A google search suggests this is https://www.internetdownloadmanager.com/.  It's installed in C:\Program Files (x86)\Internet Download Manager\idmmzcc2.xpi.  Can you please see if you can find this extension under Extensions in about:addons?  If yes, can you please disable it, restart Firefox and see if the performance of Firefox changes?  Based on the profile you submitted, I would expect things to improve massively.

Here's some technical analysis on what's happening in the profile.

It seems like this add-on is registering a content policy handler using the e10s shims, similar to bug 1331684.  We have already discussed disabling add-ons using this shim because of that bug, this is more evidence about how bad the current problem is.  Jorge, can you please add this add-on to the list of add-ons you're reaching out to if it's not there already?

To make things worse, this add-on is *also* using CPOWs, both in its shouldLoad implementation in the parent process, and elsewhere too.

I also looked at what the content processes were doing.  There are 5 content processes, 1 of them was busy loading some videos from Facebook but then was blocked on the parent due to the content policy e10s shims (which is not surprising).  There is one content process which was mostly idle but also running a bit of JS from moz-extension://58e617e2-fcb7-46b6-9e6e-00c306e23430 (which didn't seem like it had any obvious performance issues) and other content processes were mostly idle.

So the summary is that Internet Download Manager is making Firefox slow to a crawl.
Component: Tabbed Browser → Extension Compatibility
Depends on: 1331684
Flags: needinfo?(jorge)
Summary: e10s bad performance miscategorized → The Internet Download Manager add-on can seriously slow down Firefox with e10s
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've sent them an email. Shouldn't this be duped to bug 1331684?
Flags: needinfo?(jorge)
We are working intensively on moving to webextension, and we would like to implement it from Firefox 53

The current version of our extension has the following lines in install.rdf

<em:strictCompatibility>true</em:strictCompatibility>
<em:maxVersion>52.*</em:maxVersion>

and

<em:multiprocessCompatible>false</em:multiprocessCompatible>

It's not clear how users manage to run the extension in multiprocess Firefox. It's possible that they use very old versions of our extension where we did not have multiprocessCompatible set to false in install.rdf

Is it possible to find out what versions of mozilla_cc2@internetdownloadmanager.com extension were involved in the problems above?
Saad, what version of Firefox are you running?  Any chance you could please upload the XPI file at the path I mentioned in comment 8?  Thank you.
Flags: needinfo?(saad.shamsaee)
(In reply to Charles Jones from comment #10)
> We are working intensively on moving to webextension, and we would like to
> implement it from Firefox 53
> 
> The current version of our extension has the following lines in install.rdf
> 
> <em:strictCompatibility>true</em:strictCompatibility>
> <em:maxVersion>52.*</em:maxVersion>
> 
> and
> 
> <em:multiprocessCompatible>false</em:multiprocessCompatible>

This doesn't prevent the add-on from running in e10s mode, it just enables compatibility shims, and acts as a hint to the e10s staged rollout add-on. The users who have commented on this bug are running Firefox 50.
(In reply to Kris Maglione [:kmag] from comment #12)
> (In reply to Charles Jones from comment #10)
> > We are working intensively on moving to webextension, and we would like to
> > implement it from Firefox 53
> > 
> > The current version of our extension has the following lines in install.rdf
> > 
> > <em:strictCompatibility>true</em:strictCompatibility>
> > <em:maxVersion>52.*</em:maxVersion>
> > 
> > and
> > 
> > <em:multiprocessCompatible>false</em:multiprocessCompatible>
> 
> This doesn't prevent the add-on from running in e10s mode, it just enables
> compatibility shims, and acts as a hint to the e10s staged rollout add-on.
> The users who have commented on this bug are running Firefox 50.

But presumably those users were using 50 when it was in Aurora. We shouldn't ever allow people with non-multiprocessCompatible add-ons to have e10s enabled in release, right?
(In reply to :Ehsan Akhgari from comment #11)
> Saad, what version of Firefox are you running?  Any chance you could please
> upload the XPI file at the path I mentioned in comment 8?  Thank you.

i use Firefox 52beta. i disabled idm addon and now my Firefox performance is good. but not more than when e10s disabled.

sorry, my english is bad.

where to upload? you can download the last version of program from:
http://www.internetdownloadmanager.com/download.html
which file i should upload? upload to where?
We don't understand how our extension can be run in Firefox 52 beta in e10s. Is it possible without editing about:config and our install.rdf file?
(In reply to Saad Shamsaee from comment #15)
> which file i should upload?

This file: C:\Program Files (x86)\Internet Download Manager\idmmzcc2.xpi

> upload to where?

On this bug there is a Attach File link that takes you to https://bugzilla.mozilla.org/attachment.cgi?bugid=1322441&action=enter where you can upload an attachment which will appear here.

But I think it's clear what happened even without having the XPI file.  You're on 52 beta, which is compatible with this extension, and since the add-on sets multiprocessCompatible to false, you're getting the e10s shims that are slow...
Attached file idmmzcc2.xpi
Saad modifies Firefox settings and set browser.tabs.remote.force-enable to true in about:config. He forces Firefox to work in e10s with extensions that are explicitly marked as e10s incompatible. I suppose that this is not encouraged and I see no reason starting and continuing this topic
(In reply to Charles Jones from comment #19)
> Saad modifies Firefox settings and set browser.tabs.remote.force-enable to
> true in about:config. He forces Firefox to work in e10s with extensions that
> are explicitly marked as e10s incompatible. I suppose that this is not
> encouraged and I see no reason starting and continuing this topic

Is this true? I don't actually see Saad mentioning that he's doing that.

I also worry because we've not heard from the original reporter.

Andy, would you mind trying the latest release (Firefox 52). We fixed some issues that occurred with add-ons and multi-process in that build, I'd be interested in knowing if they help you.
Flags: needinfo?(andy)
(In reply to Mike Conley (:mconley) (Catching up on reviews and needinfos) from comment #20)
> (In reply to Charles Jones from comment #19)
> > Saad modifies Firefox settings and set browser.tabs.remote.force-enable to
> > true in about:config. He forces Firefox to work in e10s with extensions that
> > are explicitly marked as e10s incompatible. I suppose that this is not
> > encouraged and I see no reason starting and continuing this topic
> 
> Is this true? I don't actually see Saad mentioning that he's doing that.
> 
> I also worry because we've not heard from the original reporter.
> 
> Andy, would you mind trying the latest release (Firefox 52). We fixed some
> issues that occurred with add-ons and multi-process in that build, I'd be
> interested in knowing if they help you.

yes, it is true.
 the problem is fixed.
Flags: needinfo?(saad.shamsaee)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: