Closed Bug 495753 Opened 11 years ago Closed 10 years ago

Huge performance issue saving files


(Core :: JavaScript Engine, defect)

Windows XP
Not set





(Reporter: fehe, Unassigned)




(Keywords: hang, perf)


(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090531 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090531 Minefield/3.6a1pre

There's a huge performance problem (high CPU utilization + temporary lockup) when saving a video file (using Video DownloadHelper extension) to a folder in a drive other than "C:", if a tab also exists containing a certain type of page with jquery.js.  Confused?  Follow the steps below:

NOTE: I have also experienced the lockup when trying to save files regularly (i.e. without Video DownloadHelper), but the problem is easier to reproduce if I use Video DownloadHelper.

Reproducible: Always

Steps to Reproduce:
1. Make sure you a non-"C:" drive/partition.  A mounted external drive will also do.
2. Create a new profile
3. Install Video DownloadHelper 4.4.1 and restart
4. Load in one tab
5. Load in another tab in the same window
6. Go to Tools --> Options... --> General; and set "Always ask me where to save files"
7. Go to the tab, click to start the video; and once the video starts playing, pause it.
8. Click Tools --> DownloadHelper --> Media --> EXP306.flv
9. Once the "Save file" dialog appears, browse to a folder on the non-"C:" drive.
10. At some point during this, your computer should temporary lockup with 100 % CPU.
11. Once you regain control of your computer, cancel saving, refresh the video page, close the tab, and try again (i.e. repeat Step 8 + 9).  Notice that no lockup occurs.

NOTE: you can also reproduce with other full-length videos on the site:
Keywords: hang, perf
Version: unspecified → Trunk
Component: General → JavaScript Engine
Product: Firefox → Core
I should have mentioned (in case it isn't clear from the above) that the jquery.js issues are contributed by the web page.  Certain other pages with jquery.js will also contribute the problem.
Assignee: nobody → general
QA Contact: general → general
Would love a profile, and/or a reduced test case.  We're sure this is JS and not DOM?
(In reply to comment #2)
> Would love a profile, and/or a reduced test case.  We're sure this is JS and
> not DOM?

I was able to reproduce this with a brand-spanking new profile using the steps outlined above.  If you can't reproduce precisely following the steps outline, my profile is unlikely to help.  I'll look into this further to see if I can find some additional factor.

The reason I suspect JavaScript is because, when I profiled, I got a lot of jquery.js activity; however, jquery.js is loaded by only the tab.  This type of jquery.js invoked hang was the subject of Bug 479553.  Suspecting that, I tried again with the tab closed and the issue went away.  Double-checking by undoing the tab, the problem returned.

I don't understand DOM, but could the fact that the hang is occurring for an unrelated tab be indicative of some sort of DOM leak?
By "profile" I mean "sampling output" not "contents of your personal data directory".  It sounds like you have such a thing -- could you maybe attach it?

Wonder if we're triggering a GC and that's having to walk a lot more stuff in the jquery case?  Doesn't explain why it's fast after the first time, though!
Attached file JavaScript profile
I don't know how to do a low-level profile, so this is only a JavaScript profile.
No longer an issue.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20091126 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091126042346
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.