GUI performance dropping over time;




Shell Integration
11 years ago
9 years ago


(Reporter: L A Walsh, Unassigned)



2.0 Branch
Windows XP

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [closeme 2009-12-20])



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

It appears that as Firefox has more windows and more tabs open, the GUI thread keeps going slower and slower.  This IS NOT limited by CPU resources -- when it locks up (multi-seconds at a time), it only "sometimes" is even using the full resources of 1 CPU (25% of total on my 4P machine).  This most often locks up when I quickly go down a list of "sites", like on google news or even multiple pages like on -- I press "middle click" to open interesting tabs in background -- but after opening a few tabs, the GUI becomes sluggish and unresponsive -- ignoring button presses and any GUI updating (indeed, if I pull a window across the FF window at this point, the window won't refresh, but may be corrupt for a few seconds at a time.  

Now I don't what the GUI thread is locking up on, but there seems to be some operation(s) where it is performing the opening of other webpages (in background) *synchronously* from the main GUI thread(s).  They lock up while the background tabs "start" to open; once the tabs start displaying, the GUI will become responsive again.

Reproducible: Always

Steps to Reproduce:
1. Go to a site like google news (
2. have middle click config'ed to open tabs in background
3. start opening multiple tabs "quickly"....starts to slow down after 3rd or 4th tab and locks out the GUI.  This isn't "right".  The opens should be happening as a background operation that doesn't lock up the GUI.  Note -- it may be CPU bound on 1 processor, but it isn't CPU bound, overall, (cores>1 not used).
Actual Results:  
GUI thread gets slower and slower until it becomes unresponsive

Expected Results:  
GUI thread should stay responsive with "tab" open "enqueued" and performed in background (since they are being requested to open in background!).

Problem might become less visible if FF could use multiple cores, but on Windows, it doesn't (over 25 threads, but none will run on more than 1 core).

I feel its a fairly major flaw that the GUI window is "synchronously" performing "work" that stops it from updating and from being responsive to user input.

The flaws may be addressable on multiple "fronts" - one would be to make sure GUI thread has higher priority than background threads, but the biggest fix would be to remove "synchronous" operations from the gui thread.  It would probably help "hide" the problem if bug 392073 was fixed (allowing more cores to be used), but fixing that bug would only hide the areas where the GUI was performing synchronous operations.

Comment 1

11 years ago
Does the same happen in Safe Mode? (
Do you have a P4 with HyperThreading enabled?

Comment 2

11 years ago
I have my FF is running on a Core-Duo.  No hyperthreading enabled.

System specs: 2 Core Duo's, 4GB mem; usually with <60% commit.
I usually have FF set with affinities (set to run) on cores 0 & 1.

Comment 3

9 years ago
 L A Walsh do you still see this problem?
Keywords: perf
Whiteboard: [closeme 2009-12-20]
Version: unspecified → 2.0 Branch

Comment 4

9 years ago
=> incomplete without info from reporter
please reopen if more information becomes available per previous comments
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.