Closed Bug 1172200 Opened 9 years ago Closed 6 years ago

Since Firefox 37, Video DownloadHelper causes Firefox slowdown

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: masayuki, Unassigned)

Details

(Keywords: perf) 

A *lot* of Japanese users complain that Firefox becomes too slow in this a couple of months. I saw this claim in Twitter via Army of Awesome.

Some of them claims that Video DownloadHelper is the cause. Actually, I'm advising to disable Video DownloadHelper if you're using to such Twitter accounts. Then, most people of them thank me that disabling VDH fixed the performance problem.

So, although, I've not confirmed the fact on my environment actually, I believe that VDH must make a lot of users unhappy.

Additionally, some of them were trying to switch from Firefox to Chrome. So, this issue may cause decreasing our users. Therefore, I believe that we should take some actions ASAP.

So, we should do:

* conform whether this is true.
* check the cause, if it's bug of Firefox/Gecko or VDH.
* contact VDH developer and help them to release fixed new version even if our fault.

https://addons.mozilla.org/firefox/addon/video-downloadhelper/
http://www.downloadhelper.net/contact-us.php
As a user of Video DownloadHelper, I tend to always keep 40 to 50 tabs open in my main browser session, and i found it slow after a few days (high CPU usage). This was particularly visible when watching a video, like on YouTube, with images being refreshed once a second or more.

As the developer of Video DownloadHelper, i was very worried that this slowness could be caused by my add-on. I removed the extension from my main browser (created a separate Firefox profile for downloading videos) and after restarting the browser, the problem was gone. For a few days. And the slowness reappeared, without VDH installed.

What i mean is when users complain about Firefox being slow, if you tell them "Remove VDH and restart your browser", they are very likely to answer immediately "Yeah, that was it!", but maybe they'll changed their mind after 4-5 days, like i did.

I do not mean VDH does not introduce any slowness, but we need to be able to give it some measurements to know for sure what is to be blamed.

Also, there are a few things that are worth to be tried:

1- disabling image gallery and applet auto-detection: by default, whenever a page is loaded, javascript code is injected to detect list of links and images, as well as flash/video elements. This auto-detection defaults to "on" to match the historical settings of VDH (the gallery capture has been working that way since 2006). To disable auto-detection, the user must open VDH settings > "More", then:
  - in "Gallery capture", uncheck parameter "auto-detect"
  - in "Screen capture", uncheck parameter "applet auto-detection"
When auto-detect is off, there is still an option, "Analyze page", to trigger the detection in the current tab. I would have no problem removing auto-detection by default if we think this affects significantly the browser performance. I know this will cause many bad reviews saying the feature doesn't work anymore, but if it's really the problem, it's worth doing so.

2- A few users in VDH support forums, reported that on (some) Mac, the animation of the VDH icon in the toolbar affected the overall system CPU. I could not experience this on my own, but since 2-3 users seem to be sure of this, it deserves some credit. Here again, there is a parameter that should be changed: in VDH settings, section "Appearance", uncheck "Icon animation".

3- Hooking HTTP responses: one of the most effective way for VDH to detect videos is to monitor network activity in the browser. Without this hooking, VDH would only detect videos from YouTube and DailyMotion. The code is optimized to take as little CPU as possible (pre-compiled regular expressions, early exit when we know it's not a video) but this is code executed on each HTTP request. It has been working this way since the very first version of VDH. There is a way to disable network hooks: VDH settings > "Behavior", "Advanced" checked, uncheck parameter "Network probe". It's worth disabling network hooks to see if it significantly improves performance, but if it is the case, this would mean a big regression in Firefox. 

I am open to any suggestion regarding how to get insights of how Firefox is using its CPU and see if we can see if it can be related to VDH and what to what portion of the code.
Or maybe ...

Up to 5.3.1 (current stable release), VDH was making an intensive use of CPOW (Cross Process Object Wrappers) to workaround a buggy add-on SDK API (tabs.activeTab not reliable). The latest 5.4.0 development version (http://www.downloadhelper.net/install-beta.php?version=5.4.0a5) fixes that (the workaround is done another way). Maybe you can ask your users complaining about the slowness to give a try to this version ?
> Maybe you can ask your users complaining about the slowness to give a try to this version ?

No, I cannot, unfortunately because they're just users of Firefox, not testers.


Yassan-san, could you test it? You reproduced the bug on your environment, IIRC.
Flags: needinfo?(mozilla)
I was reproduced in 5.3.1.1-signed.
I unchecked of "auto-detect" and "applet auto-detection", was confirmed to be a little faster.

I checked the "auto-detect" and "applet auto-detection", testing with 5.4.0a5.
5.4.0a5 and Firefox 38.0.5, I don't feel slowly!

There was a case for which it takes time until it became slow in 5.3.x.
I use a few days 5.4.0a5, it will comment again if there is to be a slowly.
Flags: needinfo?(mozilla)
I think VDH 5.4.0a5 has been improved. But, I experienced to become slowdown several seconds several times. User may feel still slow.
Can you describe the slowdowns you experienced, was it when loading a page, switching between tabs, scrolling in a page ? Was auto-detection (images and applets) disabled ? Can you tell for sure it's related to VDH ?
(In reply to Michel Gutierrez from comment #6)
I experienced slowdown, switching between tabs, starting of scrolling in a page. and firefox.exe high CPU usage (almost 100%/core).
In 5.4.0a5,　even if auto-detection (images and applets) disabled, it's same.

When making VDH disabled by Extensions tab in Add-ons Manager, it doesn't become slowdown. So, I think VDH is a related problem.
I made a pass in the code to check if VDH made intensive calls to CPOW like the ones fixed in 5.4.0a5 but i couldn't find anything. Those calls only happen only on (relatively) rare events like a video being detected.

Do the slowdowns happen after some time (like hours or days) running Firefox, or can you tell now quickly whether you experience the slowdowns ?

Can you try to disable parameter "Network probe" in VDH settings > "Behavior", "Advanced" checked ? This will make VDH pretty useless but it will give an indication about where to search for ?
(In reply to Michel Gutierrez from comment #8)
The slowdowns happens several times an hour. "Network probe" is disable, it's same.
I have been using the new "about:performance" tool from Firefox nightly for some time trying to sort out the issue. It clearly shows the improvements from 5.3 to 5.4 related to CPOW, however using 5.4.0a5, there is no obvious VDH-related slowdown that appears.

Since you say you are experiencing slowdowns the same way with "network probe" disabled, this eliminated a lot of possibilities.

Once we have set auto detection to off and disabled network detection, there is only one place remaining where VDH does some active background stuff (i mean when VDH user interface is not open): whenever a youtube or dailymotion frame is loaded, VDH injects a content script into it to monitor the video id. 

I created a special version 5.4.0d2 available from http://www.downloadhelper.net/install-beta.php?version=5.4.0d2 where by default VDH does nothing: network detection off, youtube and dailymotion frames are not monitored, gallery and screen capture auto-detection are disabled, icon does not animate.

Would you mind giving a try to this version ? If you're still experiencing the slowdowns then we'll know the add-on is using CPU just doing nothing (apart from monitoring tabs and windows activations).

The parameters (accessible from "about:config") you may then then want to play with are:

extensions.dwhelper.network-probe : monitor network activity
extensions.dwhelper.tbvws.enabled : monitor YouTube frames
extensions.dwhelper.tfvws.enabled : monitor Dailymotion frames
extensions.dwhelper.medialink-auto-detect : search for images whenever a page is loaded
extensions.dwhelper.scrap.auto-detect : search for flash/video whenever a page is loaded
extensions.dwhelper.icon-animation : animate the toolbar icon when a video is detected

Many thanks for your help.
(In reply to Michel Gutierrez from comment #10)
In version 5.4.0d2, it does not experience a slow down with the exception of a single example until now.

YouTube is sometimes embedded in web site I use.　Dailymotion isn't probably embedded in web site I use.　So maybe YouTube was related to in most cases.

Possibly, Nico Nico Douga ( http://www.nicovideo.jp/video_top ) may be related. Nico Nico Douga is sometimes embedded in the website I use.

When being slowdown for more than 5 minutes, Firefox closed a tab of Nico Nico Douga, and got back several seconds later. That each once in version 5.4.0d2, in version 5.4.0a5. There is an accidental possibility for this.

The character on movie, Nico Nico Douga may be special service for VDH.

Thank you for understanding my immature English.
Thanks Yassan-san.

From what i can tell Nico Nico Douga hosts their own videos (they do not embed them from YouTube) and i confirm we don't do any special treatment with Nico Nico Douga frames (unlike YouTube and Dailymotion). So given that in 5.4.0d2, network detection is off by default, i would tend to say the slowdown you experience on this site is not related to VDH. Note that when loading a page containing containing one or several embedded videos, it is not unusual to experience slow downs, probably due to the Flash being used as a video player.

Could you confirm that after opening "about:config" and switching parameter "extensions.dwhelper.tbvws.enabled" to true (re-enabling YouTube detection), you get the slow downs back ?

If you confirm so, we have a few more things to try like injecting the content code through a frame script and not the regular addon sdk page-mod injector.
(In reply to Michel Gutierrez from comment #12)
"extensions.dwhelper.tbvws.enabled" to true in 5.4.0d2, and it was used for several hours, slowdowns wasn't experienced.
Oh, after posting comment #13, slowdowns has begun to happen.　The slowdowns in a few seconds has happened once per several minutes.

I listen radio by Flash Player. ( http://www.onsen.ag/index.html?pid=grisaia2) If the tab is closed, a slowdown has not happened any more.
As far as i can tell http://www.onsen.ag/index.html?pid=grisaia2 does not embed youtube videos. Getting slowdowns from some sites is not uncommon. For instance, take http://motherless.com/26DBA82 (warning: ads and site are Not Safe For Work), at the end of a video, ads are displayed every ~30 seconds on top of each other, not removing the element containing the previous, hence growing the DOM. As a result, open half a dozen tabs on this site and one hour later the whole browser is extremely slow. With or without VDH installed.

At this point, we know we fixed an important cause of slowdowns (CPOW) since version 5.3.1. My plan is to release 5.4.0 with this fix, auto-detection (gallery and screen capture) and icon animation off by default. We'll see if users continue to complain about VDH slowing down the browser.

I'll post here when 5.4.0 is ready (this should happen in a few days).

Many thanks for your help Yassan.
-> NEW, because of the comments
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version 5.4.0 has just been submitted to AMO.

It contains, in addition to new features and fixes, the performance-related improvements discussed in this bug entry plus a few others.
I kept using it for 5 hours until comment #14 was experienced.

I reset "extensions.dwhelper.*" . VDH 5.4.0 and Fx 38.0.5 for 4 days, VDH 5.4.0 and Fx 39.0 were used for 5 hours. A thing like comment #14 has not happened.

VDH 5.4.0 and Fx 39.0 is felt fastest in Bug 1172200.
That's good news, thanks.

Hopefully, this will be confirmed by users once 5.4.0 is approved.
VDH 5.4.1 is signed. I think that this bug is FIXED.
With WebExtensions being the only valid way of doing extensions in Firefox 57, I don't think this bug is still relevant.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.