28639 - clicking window-close "X": response time 10 sec. with 25 windows open

Status: RESOLVED WORKSFORME

(SeaMonkey :: UI Design, defect, P3)

Description

[ekrock's old account (dead)]

Using Commercial 2000012520 on Win NT 4.0 SP4 on HP Omnibook 4150 PIII-200 with 
256M. 

With a large number of windows (25) open, having been running continuously for 
an hour, when you click the "X" in the top right of a window to close it, it 
takes up to 10 seconds for the window to respond by closing.

To repro:
1) Open 25 windows to various URLs (I was using URLs from the dmoz CSS category 
at http://dmoz.org/Computers/Programming/Internet/CSS/ )
2) click the "X" in the top right of the current (active/on top) window
3) time how long it takes for the window to close

Note: I also had 5 Nav4 windows, Palm Desktop, UltraEdit, AIM, and CS&T Calendar 
running at the same time, so measured response time on other systems with 
different loading may vary. However, I think we have a UI responsiveness issue 
here.

Also, I noticed just now that I'd inadvertently launched and been using an older 
build than I intended, but I expect that results on more recent builds will be 
similar.

Comment 1

[Paul MacQuiddy]

spam: qa contact to [e-mail]

Comment 2

[verah (gone)]

Reassigning as per Don -- Trudelle, who should get this?

Comment 3

[John Morrison]

On a PIII/450/128MB machine, with 25 windows open, the window disappears
as soon as it's clicked (although it takes ~4s for the next mozilla window
to repaint when the covering window goes away). I dunno. What's the target
performance for this scenario :-]

Comment 4

[Peter Trudelle]

I'm amazed that you can get that many windows open, and I doubt we'll get to
this in the current release.  assigning to danm (for starters) as p5 for M19
marking
helpwanted.

Comment 5

[Marko Macek]

This is on Linux too. I will post a jprof run.

Using File|Quit with several dozen open windows takes about half an hour or 
so...

Comment 6

[Marko Macek]

Attachment: jprof output (ZIPPED!)

Comment 7

[Marko Macek]

Attachment: browser console output

Comment 8

[Marko Macek]

I also attached the output of browser. 

It starts destroying Webshells one by one slowly. When it came to about 20 left
it said "event stuck, removing" and exited soon after that. Either webshells are
getting leaked or something is strange...

Comment 9

[Peter Trudelle]

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

Comment 10

[Marko Macek]

This is caused by JS_GC in my observation. See also bug 39742.

JS_GC gets called from SetNewDocument which seems to get called at window close 
time.

Comment 11

[Dan M]

  Most likely this is a JS GC problem. cc:ing a JS guy and pleading for help.
  PS: Marko's "event stuck, removing" comment above implies this is also a 
problem on unix, since that message only happens (happened) on that platform. 
Changing the Platform field to reflect this.

Comment 12

[Dan M]

moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone

Comment 13

[Brendan Eich [:brendan]]

Closing down tons of windows on exit could be treated as a special case by the
DOM code: if it knew each window close were part of an Exit procedure, it could
defer GC until the last window close.  Cc'ing [e-mail].  We would need
some kind of hint or notification from the app to the dom code.  Thoughts?

/be

Comment 14

[Brendan Eich [:brendan]]

Isn't this a lot better since I fixed bug 49816, and since jst checked in the 
patch attached to bug 42321?  What is the wall-time to shut down with 10 windows 
open in M18?

/be

Comment 15

[D. Lahat]

For me, it got worse in the 2000102704 build then on the 6-Oct-2000 build. I use
Win98 with 128MB memory on Pentium 450, and with about 15-20 open windows,
closing a window takes about 2-3 seconds each. Once in a few windows, though,
it's worse and freezes Mozilla for around 30 seconds. It's usually worse with
pages containing large images. Text pages close faster.

Comment 16

[Brendan Eich [:brendan]]

Dan, anyone: can you run a profiler?  Or just break in the debugger every second 
and see what the stack looks like?

/be

Comment 17

[John Morrison]

In a crude test, I could close 10 windows in 21 seconds (450MHz/128MB). That
and [e-mail]'s comments (minus the 30 second freeze) constitute an 
improvement over when this bug was opened. [Still room for improvement, but
I think it is better than before].

Comment 18

[Dan M]

On my windows box, which is a 700 MHz not-much-for-waiting machine, it took two 
minutes to open 25 windows to mozilla.org, but just 15 seconds to close them one 
by one. I hadn't been running for an hour as the bug report suggests.

Comment 19

[Eugene Savitsky]

This and overall bug 49141 are the main paerf issues. It takes ~4-6x more time
to load/close new windows than on NS4.x :((( Basically moz it is unusable for
power browsing right now.

BTW. 49141 is dogfood, moz0.9 and P2 nomitated. Should we raise this bugs
priorities?

Comment 20

[Dvir]

This bug is probably the primary reason I don't use Mozilla / Netscape 6 every 
day. It's very limiting. I'm using Windows 98, and have been experiencing the 
issue with the program freezing for 20-30 seconds quite a lot. Other times, it's 
"just" 3-5 seconds for a screen to close. It's true, however, that you need to 
browse for something like half an hour for the really bad effects.

Comment 21

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Probably the reason it starts happening more and more is that we leak JS roots
(and the stuff that leaks from leaking them), so there's more and more stuff to
go through on each garbage collection.

Comment 22

[janne hayrynen]

i tested this by opening up about 150 empty browser windows (build 2000122121)
on linux. it appears that the newest windows close within few seconds, but
closing one of the first windows that were opened, locks me up for several
minutes (k7/600). i don't have a profiling build handy, could someone profile
this kind of situation, closing newly opened vs. first opened windows with
_lots_ of browser windows on screen?

Comment 23

[Johnny Stenback (:jst)]

I would love to see some Quantify data on Win32 for this, and what I would love
even more is if someone beats me to creating that data :-)

Comment 24

[janne hayrynen]

here's some more specific figures to my last comment:
the machine used is k7/600 with 256M ram with linux and xf86-3.3.5, mozilla
build 2000122808. after opening up 150 browser windows i wasn't on swap yet so
it didn't affect the results.
so, i opened 150 empty browser windows with ctrl-n.

-window creation time went from about 1.5s to about 5s in the end.
-closing the newest window took about 2s.
-closing the first/oldest window it took 2min 23sec with 100% cpu usage before
the window disappeared and mozilla became responsive again.

Comment 25

[Brendan Eich [:brendan]]

We don't need quantify, just a responsive gdb -- use poor man's profiling, and
hit ^C every second or faster during the longest (oldest) window-close operation
and make note of the stack backtrace.

/be

Comment 26

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Well, I took a jprof profile of closing about 40 browser windows.  Of about 9800
timer signals sent, 7548 had the following in the stack

<rdf code along with some interation with nsXULTemplateBuilder...>
RDFContainerImpl::RemoveElement(nsIRDFNode *, int)
nsWindowMediator::UnregisterWindow(nsWindowInfo *)
nsWindowMediator::UnregisterWindow(nsIXULWindow *)
nsAppShellService::UnregisterTopLevelWindow(nsIXULWindow *)
nsXULWindow::Destroy(void) [9046 total, 1470 within nsWebShell::Destroy instead]
nsWebShellWindow::Destroy(void)
nsChromeTreeOwner::Destroy(void)
GlobalWindowImpl::Close(void)

Comment 27

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

FWIW, some more stack:

[ split:       3142 TestNode::Constrain(InstantiationSet &, void *)
               3076 TestNode::Propogate(InstantiationSet &, void *)   ]
6388 nsXULTemplateBuilder::Propogate(nsIRDFResource *, nsIRDFResource *,
                                     nsIRDFNode *, ClusterKeySet &)
6838 nsXULTemplateBuilder::OnAssert(nsIRDFDataSource *, nsIRDFResource *,
                                    nsIRDFResource *, nsIRDFNode *)
6873 CompositeDataSourceImpl::OnAssert(nsIRDFDataSource *, nsIRDFResource *,
                                       nsIRDFResource *, nsIRDFNode *)
6888 InMemoryDataSource::Assert(nsIRDFResource *, nsIRDFResource *,
                                nsIRDFNode *, int)
7520 RDFContainerImpl::Renumber(int, int)
7548 RDFContainerImpl::RemoveElement(nsIRDFNode *, int)

Comment 28

[Chris Waterson]

I suspect that this has to do with my crappy implementation of RDF sequences 
vis-a-vis the in-memory datasource (which is what the window mediator uses). 
danm, rjc and I had been working on improving the performance for stuff like 
this; it's the same problem that we're having with very large bookmark folders. 
You can reassign the bug to me, unless you'd like to get down and nasty with 
RDF... ;-)

Comment 29

[Dan M]

Damn! All that time is just spent taking the windows out of the RDF datasource? 
That's surprising. But more to the point, it belongs to Chris Down-'n-Nasty 
Waterson now. Woo hoo!

Comment 30

[Johnny Stenback (:jst)]

Removing future milestone and nominating for nsbeta1 to get this re-evaluated. I
think this performance problem is something that's worth looking into for the
next release.

Comment 31

[Paul Chen]

nav triage team:

Marking nsbeta1+

Comment 32

[Arthur]

Cc'ing myself, anyone working on this?

Comment 33

[Randell Jesup [:jesup] (needinfo me)]

See also bug 104127 for up-to-date jprofs

Comment 34

[Boris Zbarsky [:bzbarsky]]

*** Bug 127955 has been marked as a duplicate of this bug. ***

Comment 35

[Robert John Churchill]

I would expect that this situation has improved now that bug # 104127 has been
fixed.

Comment 36

[Tim Olson]

Just went to release 1.2.1 yesterday and suddenly even with only 1 or 2
browser windows open it takes maybe 5 to 7 seconds to close when you hit
the "X" (top right).  Compared to IE 5.5 and other browsers this is far
far longer.  Was loving my mozilla at 1.2a, but with 1.2.1 it's annoying
as heck.

Comment 37

[Tim Olson]

Just went to release 1.2.1 yesterday and suddenly even with only 1 or 2
browser windows open it takes maybe 5 to 7 seconds to close when you hit
the "X" (top right).  Compared to IE 5.5 and other browsers this is far
far longer.  Was loving my mozilla at 1.2a, but with 1.2.1 it's annoying
as heck.

Hardware:  Compaq EVO N800c laptop 1.8Ghz/512Mb   Win2Kpro
running release 1.2.1 of Mozilla.

Comment 38

[pseudogratix]

PIII 730MHz box with XP running. Never had this problem with any of the latest
builds (at not in recent memory), but when I started using 1.2.1, even with just
one browser window open, closing the window takes 5 or more seconds (even pop-up
windows). BTW, the latest build (at least not 20021210 to 20021212) doesn't have
this problem. It is almost as if it was added to 1.2.1. It is almost as annoying
as shutting down MS Word XP.

Comment 39

[John Morrison]

How many bookmarks do you have. Bug 182842

Comment 40

[Harry]

I have this problem also, using Mozilla 1.3a build 2002121215.  When I click the
X to close a Moz browser window, all open browser windows go gray and it takes 5
- 10 seconds to close that window (Pentium 4 1800mHz).  I can't swap over to the
other open Moz windows until it that window closes, but can swap over to other
applications.  I don't use quicklaunch for Moz.    

I did not, however, have this problem in Moz 1.2.1.  The problem started as soon
as I started using Moz 1.3a, with the same number of bookmarks as I had in Moz
1.2.1.  I had done a "clean" install (uninstalled Moz 1.2.1 then installed Moz
1.3a).  Java is turned off, I'm using pipelining but no proxy.  I don't use
tabbed browsing.  I'm running on Win 98 with 512M RAM.  

I hope that information is helpful.

Comment 41

[Harry]

I downloaded and installed nightly build 2002122808, and it didn't make any
difference.  

I had seen in comments 28 and 39 that there were problems with large bookmark
files, so I took a look at mine...It was 972k.  So, I made a copy of it and
deleted all bookmarks other than my "personal toolbar" bookmarks which got it
down to 4k.  Yeah, bad habit of bookmarking anything that looks remotely
interesting :)  Once I determined that this was the solution, I simply
bookmarked the old bookmark file on my hard-drive so I'd still have easy access
to my old links without the overhead of the huge bookmark file.

Bottom line is, I no longer had the problem once I pared down the bookmarks to a
reasonable filesize.  So, size DOES matter :)  At least it matters when it's too
large...This is an already-reported bug according to other posts here, the
bookmark bug number is <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=182842">182842</a>.

Yay!  Searching Bugzilla saves the day for me again!  I'm a happy camper again,
and I didn't have to mess with anything other than the bookmark file.  I'm still
a little confused about why I didn't have a problem with the large bookmark file
in Moz 1.2.1, but maybe I'm just remembering wrong.  Hmmm...I might just have to
test that theory later.  If I do, I'll post my results here.

Comment 42

[Wayne Mery (:wsmwk)]

WFM windows Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051205 SeaMonkey/1.5a

perhaps resolved with fixing of Bug 182842 and other perf bugs?

is this still an issue for linux? 

Comment 43

[Wayne Mery (:wsmwk)]

Andrew, 
do you agree this bug and 
 bug 39742
 bug 104176
 bug 99053
 bug 83421
and any other linked bugs are gone?

I believe this is fixed via bug 182842 and bug 104127 and probably some others.

Comment 44

[Wayne Mery (:wsmwk)]

=> WFM