Closed Bug 78077 Opened 24 years ago Closed 22 years ago

Window opening times get really slow after opening multiple browser windows (on win32)

Categories

(Core :: XUL, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME
Future

People

(Reporter: jrgmorrison, Assigned: hyatt)

References

Details

(Keywords: perf, topperf, Whiteboard: [nav+perf])

Attachments

(4 files)

Overview Description: So, I set up this test (which I'll attach to this bug) to open a series of windows from a simple xul window, measuring times along the way by having the opened window call back to it's opener with the current time. I have it set up so that it goes through a sequence, first opening and immediately closing 10 windows (so only one navigator window is open at the same times), and then opening 10 windows in succession and then closing all 10. It then repeats these 20 window opens five more times (total 100 windows are opened). The script waits until each window is fully open before scheduling the next window open, so no two windows are ever active at the same time. After running an initial set of tests, I found that there is a very odd problem on win32 (at least on win2k). Basically, open >1 window concurrently on win32 can result in some very slow window creation times. I'll attach a chart to show what I mean (and a comparison chart that shows that Linux and Mac to not demonstrate this bug). Steps to Reproduce: 1) download the attached script, and it's companion HTML document into the same directory. 2) (Semi-optional) shut down all other running applications; create a new profile; collapse the sidebar by clicking on the grippy; switch to classic skin; enter the URL: 'javascript:window.innerWidth=700;window.innerHeight=500' into the URL bar; shut down mozilla 3) Win32: Start mozilla with 'mozilla -chrome file://c:/foo/winopen.xul' Linux: Start mozilla with 'mozilla -chrome file:///foo/winopen.xul' Mac: Create a file with two lines in it: 'ARGS:-chrome' 'ARGS:file:///Macintosh%20HD/foo/winopen.xul' and drop that file onto mozilla. (Adjust the filenames above as appropriate). Actual Results: See the chart Expected Results: Window opening times should be ~constant for 'windows < 10' Reproducibility: 100% The windows chart shows two runs done under the same conditions, with very little deviation in the results of the two runs. However, the actual window opening times _may_ be a function of window geometry, toolbar/sidebar state, choice of skin, NT vs. 9x, etc. ... Build Date & Platform Bug Found: 2001-04-27-06-Mtrunk win2k comm. build 2001-04-28-06-Mtrunk linux comm. build 2001-04-27-04-Mtrunk mac comm. build Additional Information: I also noticed this curious pattern in memory usage while running the test on win2k (I didn't see this on Linux; don't know how to check in real time on Mac). From window 1 to 10 -- 20 MB, rising to 36 MB at window 20, back down to 27 MB for window 21-30, rising to 37 MB at window 40, back down to 31 MB for window 41-50, rising to 38 MB at window 60, back down to 33 MB for window 61-70, rising to 38 MB at window 80, back down to 35 MB for window 81-90, rising to 39 MB at window 100. (i.e., releasing less and less of the peak memory after each 10-in-a-row series. Note also that 'single open' times are steadily rising, from ~1100 for 1-10, to ~1700 for 81-90). I've tried this manually on the same win32 system, and just pressing Ctrl-N and counting in my head, I could see that the effect is there in "normal" use. Window opening can get really slow after you have opened a bunch of windows.
Severity: normal → major
Doesn't happen on all machines. --> Future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Blocks: 49141
Window opening time is too slow anyway: even popping up something as simple as the "find in page" dialog takes one to two seconds on my machine (K6-2/300, Linux). This same goes for closing a window: destroying it takes too much time to give Mozilla that quick&snappy user experience.
Whiteboard: [nav+perf]
Blocks: 104166
Seems as if this bug is a duplicate of bug #125100 and bug #127634. I hope this gets fixed soon.
Is this one still valid?
No, this doesn't particularly happen now.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: