495753 - Huge performance issue saving files

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[IU]

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 http://www.directdial.com/99B-01948.html in one tab
5. Load http://www.pbs.org/wnet/expose/2009/03/the-peoples-sheriff.html 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 pbs.org 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 directdial.com 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: http://www.pbs.org/wnet/expose/episodes/?episodes

Comment 1

[IU]

I should have mentioned (in case it isn't clear from the above) that the jquery.js issues are contributed by the directdial.com web page.  Certain other pages with jquery.js will also contribute the problem.

Comment 2

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Would love a profile, and/or a reduced test case.  We're sure this is JS and not DOM?

Comment 3

[IU]

(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 directdial.com tab.  This type of jquery.js invoked hang was the subject of Bug 479553.  Suspecting that, I tried again with the directdial.com tab closed and the issue went away.  Double-checking by undoing the directdial.com 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?

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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!

Comment 5

[IU]

Attachment: JavaScript profile

I don't know how to do a low-level profile, so this is only a JavaScript profile.

Comment 6

[IU]

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