High CPU usage in Flash causes setInterval() timers to starve

RESOLVED WORKSFORME

Status

()

--
critical
RESOLVED WORKSFORME
11 years ago
9 years ago

People

(Reporter: darrick, Unassigned)

Tracking

({perf})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13

When a Flash movie is on the page that uses a large amount of video and CPU power, Firefox starves any timers running.  When under load, Firefox timers (setTimeout(), setInterval()) do not fire.  This problem is reproducible 100% of the time on slower/lower end Windows XP machines.  If the machine is higher end, the bug may only reproduce occasionally or not at all.  So when attempting to reproduce this bug, please use a lower end machine or Windows XP in a VM (WinXP on Parallels on my MacBook Pro reproduces this problem every time).

Reproducible: Always

Steps to Reproduce:
1. On Windows XP, in Firefox 2.0.0.13, open: http://preview.videoegg.com/firefox/loadtest.html
This page contains an 800x600 video on the left and a textarea on the right.  The 800x600 video is intended to use up a good chunk of CPU/video.
2. Do not play the video yet.  The textarea at the right prints the current time every second on a js timer created with setInterval().  Notice the timer is firing correctly.
3. Play the video.  Notice the timer hangs while the video is playing.
4. Pause the video.  Notice the timer resumes its expected behavior.

Bonus:

1. Open multiple tabs in Firefox.
2. Play the video.
3. Notice that you can't click between tabs while the video is playing.
4. Pause the video.  Suddenly, Firefox swaps to the last tab clicked.
Actual Results:  
While video is playing, js timers and switching between browser tabs do not work, or are extremely laggy.  The events are getting starved.  It appears that Firefox may be attempting to improve Flash/plugin performance by servicing it on a higher priority basis.  However, this scheduling is starving other necessary events.

Expected Results:  
All events should be serviced in a reasonable manner without any events being starved.  Under load, I would expect things to run a bit slower, but all events should get through.

This bug happens most readily when Flash has its window mode set to "transparent" or "opaque" ("windowless" mode in the NPAPI), which uses more CPU.
(Reporter)

Updated

11 years ago
Flags: blocking1.8.1.14?
(Reporter)

Comment 1

11 years ago
Firefox 3.0 appears to handle this case fine.  However, that might be due to all the performance enhancements that went into 3.0.  Perhaps the bug is still in there, but the performance improvements in 3.0 allow the events to be serviced ok.  The bug may still be lurking in there.  It's probably worthwhile to investigate the root cause of the issue in 2.0 and make sure that 3.0 isn't simply masking it.
(Reporter)

Updated

11 years ago
Flags: blocking-firefox3?
(Reporter)

Comment 2

11 years ago
Setting blocking flags as instructed by Damon Sicore.
This would be a Core bug, in any case.  We've changed a lot of things beyond perf that should help with this on trunk, like better timers, etc.
Component: General → General
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: general → general
Fix would be nice, but not a "blocking" bug.
Flags: blocking1.8.1.15?

Comment 5

10 years ago
Created attachment 318142 [details]
test setInterval()

Test-case shows CPU load under varying conditions when using setInterval()
(instructions on page)

The problem depends on the complexity in the function called by setInterval()

Using a timer to load a small document on regular intervals (2 sec) by XMLHttpRequest are now using about 50% CPU capacity in a very 'un-nice' way

Comment 6

10 years ago
Comment on attachment 318142 [details]
test setInterval()

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14

The hight CPU load reported in my test-case was due to exhausted memory caused by a memory leak in mozilla.

Lack of memory caused disk-swap which gives a CPU load of 100%, indicating a very selfish disk-swap routine (?)

Comment 7

10 years ago
high cpu also with v3.1.  But no lockout or UI delay.
Is this still deemed a problem with v3.1. And if it is, isn't this a duplicate?
Keywords: perf

Comment 8

9 years ago
OK, since the original bug doesn't happen in 3.0, resolving this bug. Darrick, thanks for your report and the updates, but realistically, there's no chance the issue will be separately debugged in 2.0 to check if there may still be an (invisible) issue in 3.0...

Terje: thanks for the testcase. It's not related to this bug at all though. If you can still reproduce with the latest build (I can't; see http://nightly.mozilla.org/ for links to the latests builds), please open a separate bug about it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.