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

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[John Morrison]

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.

Comment 1

[John Morrison]

Attachment: window open test; save as 'winopen.xul'

Comment 2

[John Morrison]

Attachment: companion html file; save as 'child-window.html'

Comment 3

[John Morrison]

Attachment: window opening times for 10x10 window opens on win2k

Comment 4

[John Morrison]

Attachment: window opening times for 10x10 window opens on mac and linux

Comment 5

[David Hyatt]

Doesn't happen on all machines.  --> Future.

Comment 6

[Erik Hensema]

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.

Comment 7

[M. A. Sridhar]

Seems as if this bug is a duplicate of bug #125100 and bug #127634. I hope this
gets fixed soon.

Comment 8

[Markus Hübner]

Is this one still valid?

Comment 9

[John Morrison]

No, this doesn't particularly happen now.