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)
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.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
Reporter | ||
Comment 4•24 years ago
|
||
Reporter | ||
Updated•24 years ago
|
Severity: normal → major
Assignee | ||
Comment 5•23 years ago
|
||
Doesn't happen on all machines. --> Future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 6•23 years ago
|
||
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.
Updated•23 years ago
|
Whiteboard: [nav+perf]
Comment 7•23 years ago
|
||
Seems as if this bug is a duplicate of bug #125100 and bug #127634. I hope this
gets fixed soon.
Comment 8•22 years ago
|
||
Is this one still valid?
Reporter | ||
Comment 9•22 years ago
|
||
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.
Description
•