Closed
Bug 28639
Opened 25 years ago
Closed 17 years ago
clicking window-close "X": response time 10 sec. with 25 windows open
Categories
(SeaMonkey :: UI Design, defect, P3)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
WORKSFORME
Future
People
(Reporter: ekrock, Assigned: jag+mozilla)
References
Details
(Keywords: helpwanted, perf, Whiteboard: nsbeta1+)
Attachments
(2 files)
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 2•24 years ago
|
||
Reassigning as per Don -- Trudelle, who should get this?
Assignee: don → trudelle
Comment 3•24 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•24 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.
Comment 5•24 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•24 years ago
|
||
Comment 7•24 years ago
|
||
Comment 8•24 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•24 years ago
|
||
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
Comment 10•24 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•24 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•24 years ago
|
||
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M21 → Future
Comment 13•24 years ago
|
||
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
Comment 14•24 years ago
|
||
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•24 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.
Comment 16•24 years ago
|
||
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•24 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•24 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•24 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•24 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•24 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?
Comment 23•24 years ago
|
||
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•24 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.
Comment 25•24 years ago
|
||
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•24 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•24 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
Keywords: mozilla1.0
Comment 30•24 years ago
|
||
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.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Blocks: 83421
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla1.0
Comment 32•23 years ago
|
||
Cc'ing myself, anyone working on this?
Comment 33•23 years ago
|
||
See also bug 104127 for up-to-date jprofs
Updated•23 years ago
|
Target Milestone: mozilla1.0 → Future
Comment 34•23 years ago
|
||
*** Bug 127955 has been marked as a duplicate of this bug. ***
Comment 35•22 years ago
|
||
I would expect that this situation has improved now that bug # 104127 has been fixed.
Comment 36•22 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•22 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•22 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•22 years ago
|
||
How many bookmarks do you have. Bug 182842
Comment 40•22 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•22 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.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 42•19 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•17 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•17 years ago
|
||
=> WFM
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•