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.
spam: qa contact to firstname.lastname@example.org
QA Contact: paulmac → jrgm
Reassigning as per Don -- Trudelle, who should get this?
Assignee: don → trudelle
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 :-]
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
Priority: P3 → P5
Target Milestone: --- → M19
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...
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...
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
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.
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
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 email@example.com. We would need some kind of hint or notification from the app to the dom code. Thoughts? /be
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
In a crude test, I could close 10 windows in 21 seconds (450MHz/128MB). That and firstname.lastname@example.org'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].
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.
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?
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.
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 :-)
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)
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... ;-)
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.
Priority: P5 → P3
Target Milestone: Future → ---
nav triage team: Marking nsbeta1+
Cc'ing myself, anyone working on this?
See also bug 104127 for up-to-date jprofs
*** 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.
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.
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.
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.
How many bookmarks do you have. Bug 182842
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.
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.
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
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.