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

RESOLVED WORKSFORME

Status

P3
normal
RESOLVED WORKSFORME
19 years ago
8 years ago

People

(Reporter: ekrock, Assigned: jag-mozilla)

Tracking

({helpwanted, perf})

Trunk
Future
helpwanted, perf
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nsbeta1+)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Updated

19 years ago
Keywords: perf

Comment 1

19 years ago
spam: qa contact to jrgm@netscape.com
QA Contact: paulmac → jrgm

Comment 2

19 years ago
Reassigning as per Don -- Trudelle, who should get this?
Assignee: don → trudelle

Comment 3

19 years ago
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

19 years ago
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.
Assignee: trudelle → danm
Keywords: helpwanted
Priority: P3 → P5
Target Milestone: --- → M19

Comment 5

19 years ago
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

19 years ago
Created attachment 8776 [details]
jprof output (ZIPPED!)

Comment 7

19 years ago
Created attachment 8777 [details]
browser console output

Comment 8

19 years ago
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

19 years ago
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21

Comment 10

19 years ago
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

18 years ago
  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.
OS: Windows NT → All
Hardware: PC → All

Comment 12

18 years ago
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M21 → Future
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 jst@netscape.com.  We would need
some kind of hint or notification from the app to the dom code.  Thoughts?

/be
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

18 years ago
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.
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

18 years ago
In a crude test, I could close 10 windows in 21 seconds (450MHz/128MB). That
and dlahat@ibm.net'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

18 years ago
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

18 years ago
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

18 years ago
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.
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

18 years ago
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?
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

18 years ago
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.
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
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)
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

18 years ago
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

18 years ago
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!
Assignee: danm → waterson
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.
Keywords: nsbeta1
Priority: P5 → P3
Target Milestone: Future → ---

Comment 31

18 years ago
nav triage team:

Marking nsbeta1+
Whiteboard: nsbeta1+

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla1.0

Comment 32

17 years ago
Cc'ing myself, anyone working on this?

Updated

17 years ago
Blocks: 99053

Updated

17 years ago
Blocks: 104166
See also bug 104127 for up-to-date jprofs

Updated

17 years ago
Target Milestone: mozilla1.0 → Future
*** Bug 127955 has been marked as a duplicate of this bug. ***
I would expect that this situation has improved now that bug # 104127 has been
fixed.

Comment 36

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
How many bookmarks do you have. Bug 182842

Comment 40

16 years ago
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

16 years ago
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.

Product: Core → Mozilla Application Suite

Comment 42

13 years ago
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? 
Assignee: waterson → jag
Status: ASSIGNED → NEW
QA Contact: jrgmorrison

Comment 43

12 years ago
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

11 years ago
=> WFM
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME

Updated

8 years ago
No longer blocks: 99053
You need to log in before you can comment on or make changes to this bug.