We've determined that New Window performance is the number 1 issue which is hindering adoption of Mac dogfood. This includes both creation of the first window of a kind (ie. non-cached XUL), and subsequent windows (from XUL cache).

keywords

Waterson is swamped -> ducarroz

Opening new windows is, apart from crashes and data loss bugs, my number one dogfood stopper, too. Must be at <=1s to be usable, pretty much every document (mails or webpages) goes into a new window for me. Adding dogfood.

This is a completely dreadful problem on unix also. Changing platform to 'all'.

Adding bug 42321 as a factor.

Putting on [dogfood+] radar

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

Can someone put in the current performance figures for new window on the impacted platforms (mac/linux)? Please include a statement of what machine was being used (memory available, and processor speed). I'm running on build 2000082313 (non-debug) On a 300Mhz NT box, with 70megs still free, it takes 1.6 seconds (on my stop watch). IMO, this is very usable (re: it is longer than Ben said was usable... but we have different tolerances) Can anyone tell me if we have performance tools that can be used to diagnose mac specific issues in the window startup? Adam Mosses comment about GC above is quite interesting: Can we verify/deny that this GC interval is what is significantly hurting us? What is the cost of the GC as a portion of the window startup? on the mac? on linux? Thanks, Jim

um, jar, wasn't the point of this bug to get it fixed on mac, not just say "oh, well, it's good on win32 so it's good enough?"

we have two kinds of perf tools, one like Quantify (the MW profiler) and an instrumentation library. even on 450MHz G4's with 256MB of RAM, this is certainly slower than 1.6 seconds (yes, optimized builds too). I don't have any exact numbers yet. remember, this affects html performance as well (remember those popup ads that netcenter and AOL seem to love these days?...and need i even mention porn sites?). Do we want to guarantee that the AOL and Netcenter homepages are slower on our product than any other on the market? Don't dismiss this bug by saying "well i have one window open, so i just won't open any more."

My stopwatch says 8.5 sec on a 266 G3 Mac, 96 Megs RAM.

taking this bug after talking to ducarroz.

> this is certainly slower than 1.6 seconds I (manually) count > 3s for a new blank browser window on Linux, optimzed, Celeron 300A, 128MB (80% used). > Do we want to guarantee that the AOL and Netcenter homepages are slower > on our product than any other on the market? Good point. Add to that the fact that Gecko seems unable to draw 2 windows as the same time, and draws the UI. Within these 3s (for me), Mozilla is completely unresponsible, it doesn't even redraw.

8 seconds sounds terrible. We should probably focus on mac performance tools, rather than look to fallout from linux tools. Note that my 1.6 seconds was the delay from when I clicked "new window" till I saw the window starting to draw. IMO, that delay is potentially the most damning, as it leaves the user wondering if they really clicked. I'm curious... was the 8 seconds till completion, or till the window began drawing, and the user had *any* feedback that we were servicing the the request?

8 seconds is until a new window becomes usable. There is a period of around 3-5 sec of waiting until a new window appears, then everything freezes (Moz, OS, etc) until the window draws, and a page appears, at which point Mozilla becomes usable again, about 8 seconds latter. It's worse if the background window is rendering, or the new window is more complicated then, say, the mozilla.org homepage. Tow weeks ago, it was getting better, but the newest builds have returned to the agonizingly long delays.

Is there any way that we can cheat? I've noticed that CPU also jumps pretty high on new windows for a second even on NT. To get something up quicker for the user to see, is there any way that we could pre-load in memory a new window such as about:blank like a "template", with the chrome and everything else, up to the point that the document is fetched? Make it invisible until a new window needs to appear. That way, we don't have to re- invent the wheel every time and opening a new window should be almost as fast as clicking on a link. However, this would surely increase bloat, so perhaps an #IFDEF for platforms that would gain the most performance?

Peter: that is pretty much what we do. We create a XUL prototype document from the first window read in, and 'clone' that for additional windows of the same kind. We've called this "brutal sharing". But it's still too slow.

Do we have any data yet on what specifically is sucking time?

pink is working on it right now.

very preliminary numbers: - time from menu selected ("New Navigator Window") to new window made visible (nsMacWindow::Show(), 2nd window, all in xul cache): 2.5 seconds - time from showing window to activate/update/paint event processing complete: about 1 second this is for the navigator window, debug build, 450MHZ G4. the first chunk for "open new location" dialog is only about a second. I'm about to start delving into that first chunk of time now.

Notes (This references the attached screenshot from the Instrumentation SDK) What I did was launch mozilla (which opens a browser window at startup) then select "File:New Browser Window" to open a second one. The timing begins in the MenuItemSelected row in purple which fires when the mouse is released on the menu item. The window becomes visible 2.6 seconds later, shown by the marks in dark orange in the "Window Made Visible" row. Each gray vertical line marks one second in real time. The bulk of time before the window is displayed is spend creating the window. nsXULDocument::ResumeWalk() dominates the time taking 65% (1.7 seconds). Of that time, 1.12 seconds (43% of total time) is spend in nsPresShell::InitialReflow() creating the frames (the frame creation from nsCSSFrameCtor::ConstructFrameInternal() is illustrated in light orange). The user is totally locked out during this time. I don't yet know exactly what the remaining 0.6 seconds of ResumeWalk() is doing. Another interesting thing is how many times we hit the style system during this whole process (shown in blue). After the initial reflow, about:blank is loaded in the content area, which takes 0.2 seconds (7% of total). Note that we also do this _again_ after we show the window so in total we spend 0.35 seconds (13%) loading about:blank. I mention this because during the load of about:blank, whose time is dominated by frame creation of the GFX scrollbar, user interaction is locked out as well. After about:blank loads, we start processing DOM events, the largest of which being the page loaded event taking 0.33 seconds (12.6% of total time). I'm not sure what we're doing in here yet. Haven't profiled it.

waterson asked, so I just did another build with #undef DEBUG and the total time is cut in half (now 1.3 seconds) but the relative times all look the same. Remember, this is 1.3 seconds to when the window is shown with about:blank, not to when painting is done, and not until the user has the ability to interact with the UI (on a really fast machine). 4.7 opens a new window instantly on this machine. I'm about to try using the profiler, we'll see how well it works.

i have profiler data for nsXULDocument::ResumeWalk() for the open location dialog if anyone wants to see it. It's dominated by CSS slowing down frame creation. memory and string stuff aren't high on the list, which surprises me a little.

Adding pierre for CSS performance issues.

marking this as a dependency of the fact that windows repaint slowly. I have some good data while I'll put on that bug (48274). Basically, we're spending most of the time to paint the window in FillRect painting the entire window, relying on clipping to only paint the correct thing. We repaint the entire window probably about 10 times handling the single paint event. details in that bug.

how about new window times in say 4.x on mac for performance comparison?

It is hard to give actual numbers for new windows with 4.x on Mac as they open rather instantly. The best I could come up with is .45 sec which I know is too long, because my reaction time w/ a stopwatch is not that great. Essentaly, if I hit command-N to open a new window, as soon as I let go, the window has appeared (blank window, if it a window with something in it, the window still appears instantly, and Netscape is still usable instantly, however there is obviously some load time for the window's contents) This is all on a 266 G3, w/ 96M physical RAM.

Just a bit of an asside, but not really. How does the release of Mac OS X beta in 9 days affect this. At beta launch, many will flock to the new OS. Will Mozilla be ready?

PDT agrees P2

PDT marking nsbeta3-, nominating for rtm

mass-adding rtm keyword to all open nsbeta3+ xptoolkit bugs

This is better now, but not enough to declare victory. Dependencies have been futured, so.... ->future

rtm-

Please remember that this is still [DOGFOOD+]. Nominating for mozilla0.9.

d'oh, yeah, thanks! removing dogfood+ for reconsideration. If this is still dogfood, then we should probably mark the dependencies dogfood+ too, otherwise there is no way to fix this.

It sounds like we've improved this some... and perchance it is no longer dogfood. Peter's comment suggests that some individual bug that this depends on might be considered as the real item to focus on further. Marking dogfood-minus (and waiting for renomination if needed).

jar, I don't think, this improved much. And Netscape's N6 schedule has no influence on Mozilla dogfood ;->. I know, it's your resources, but still... I cannot nominate specific bugs, because I have no idea which one. All I know is that *this* bug needs to be fixed or at least vastly improved.

'needs to be fixed' is not the definition of dogfood, 'stops significant number of contributors from using the product for their daily needs' is. Who is this stopping from using the product?

Peter, this is one of the most important issues keeping me from using mozilla or N6 for everyday use. Speeding up new window performance would make mozilla much more enjoyable to use. It takes ~3 seconds on a 900MHz P3 to open each new window on my computer using recent builds. (900MHz, 128mb, win2k, 56k). Its pretty annoying, and is probably on the order of 30 times slower than 4.x (on 4.x it opens pretty much instantly). It also makes reading news unbearable, since I like to double-click the message and have it open in a new window. 3 seconds x 50 Messages is really frustrating. (Maybe a pref to reuse the window that messages pop up in would make things more bearable.) In my mind this bug should be dogfood but there are lots of other bugs, and I understand that 6.0 needs to ship soon.

I know it is a defect, annoying/frustrating, slower than 4.x, and the fix would make things more enjoyable, but is it really *preventing* you from using the product? Couldn't you read news messages in the mail window's message pane, or navigate between messages in a separate window rather than double-clicking on each one? Dogfood doesn't mean 4-star cuisine!

pete@verticaljump.com, are you using an optimized build? Do you have a 900Mhz machine? Or 90Mhz machine? On my 750Mhz machine with Win2k, it takes l.t. 1sec to open a window. Make sure that you have your XUL cache turned on. Finally, what page are you trying to open? Try with "about:blank" as a default.

Trudelle, PDT, my own experience: Why new windows: I open a new window for pretty much every content I open. This is the way I browse, and I got so habituated to it, that I cannot or don't want to change it. This is also the way I use mail because - loading a msg I want to delete is - dangerous (bug 28237) - slow - deleting a msg open the next msg and marks it read, but I don't want to read sequentially. Speed: I felt that it was so slow (~3.5s for a new blank window, freezing everything else, so I cannot even read the content of another window in this time) that it took me twice as much time to use Mozilla than 4.x. It just isn't worth that much time. => Preventing dogfood. Things changed instantly when I recently upgraded from Cerleron 300A to AMD Duron 650 (same machine, both 128 MB RAM). Now, the new window opens within 1s, and I start using Mozilla. (But it is still too slow to be good.) Maybe you guys should just use slowed machines sometimes? :->

Oh, and please consider that - a huge chunk of N6' target group (private users, newbie to average) still uses Pentium I. - you don't have to be a open-in-new-window fanatic to see this. Just go to <http://www.home.netscape.com> or http://www.geocities.com/*, as Mike Pinkerton 2000-08-25 11:02 pointed out.

I don't think this is essential for Mozilla 0.9 somehow... Version 1.0, yes, I would think so. I agree it may not be "enjoyable" to keep using Mozilla this way, but does it really *prevent* you from using it, the way a 100% reproducible crash on a top 100 site would? No... This bug does not prevent Mozilla's use. It merely makes Mozilla "unenjoyable." (And terms like this are rather vague in this context.) No, I don't think this should be dogfood somehow. As Peter says, dogfood is not meant to be 4-star cuisine. However, let's look at it this way: Opening new windows is an operation which is so common that it may affect public acceptance of Netscape 6.0 as opposed to a competitor like say Opera or IE, both of which open new windows instantly on THE SAME HARDWARE. And I agree, not every one of us has the ability to afford the latest 900 MHz Pentium III/Athlon machines the way Netscape does. Bearing in mind that this could be a serious competitive hurdle when browsing even Netscape's very own Netcenter, which opens new windows for things like popup ads, I would like PDT to re-consider the RTM tag... If they still think rtm-, I will understand, since I do also see that time pressures may outweigh this consideration.

On second thoughts, never mind. I have just taken another look at this on my measly 566 MHz Celeron system, and see that it takes <1 second to load with an optimized build here. Still not optimal, I'll agree, but I think this may still be good enough for public acceptance. Someone want to mark this rtm- and dogfood- again? This can wait to be fixed after the NS6.0 release. (I assume that's why we leave this bug open.)

> but does it really *prevent* you from using it, the way a 100% reproducible > crash on a top 100 site would? No... I just outlined that it in fact does. Do you think, I'm lying? For dogfood, this is *much* worse than a top100 crash. For top100, the workaround is not to visit this particular site. For this bug, the workaround is to - waste 3+ hs per day (because you need twice as much time to browse / read mail with Mozilla) or - use another browser suite.

oh, or - spend 500$ to buy a new processor + mainboard.

while this isn't as fast as 4.x, it is perfectly acceptable on my G4 on optimized builds. I open new windows all over the place, and it's fine. I even tried it on my G3 300 running under the blue box and it still was OK. *shrug*

Thanks Chris! I just looked, and my XUL Cache was turned off. Opening a new window now takes less than 1sec also, using nightly build 2000100320. Cruising in Mozilla *feels* about 10x faster now. :-)

> it still was OK Can you give a thumb-number how long it takes to open an empty new browser window? I argue that anything >1s is dogfood-relevant.

Some data from here -- Linux x86, 5x86-PR233, optimized build. Opening a new blank window after a while of general surfing: 8sec. Opening another new window immediately afterwards: 2.5sec.

Ah, just another note while I'm 'here'... new-window performance is *distinctly unpleasant* (I share Ben's browsing style) but I can't honestly say that it's preventing *me* from eating dogfood. I'd be willing to believe anyone who said that it was truly intolerably frustrating for them, though.

I think that we should still get a PDT re-evaluation for RTM, even if it is made DOGFOOD- again. They ought to be able to tell better than we can at this point whether these issues, which I think are VERY real, and could make people defect from Netscape to competitors like IE or Opera, outweigh the need to get SOMETHING released. After all, while Netscape could take the time to get these problems worked out and win more loyal users by doing this, they also lose more and more potential customers everyday by NOT releasing SOMETHING ASAP. Lord knows they have lost a lot of momentum already.

If I visited a site like theregister.co.uk all the time (were I always open 10-20 new windows), then new window performance would be dogfood, but I don't. Regardless, I think performance has improved enough for this not to be a critical issue as it was clearly before. In the latest nightly, there is no more debug menu in preferences. Is there a way to verify my xul cache settings, and is the nightly the optimized build?

Check if you have a pref named nglayout.debug.disable_xul_cache defined in the prefs.js file for you current profile. If it's the case either remove it or set the value to false (quit Mozilla first)

It sounds like most folks are not using this as a reason to avoid Nav 6, so I'm putting this back at dogfood minus. Note that this doesn't prevent work on it. It is already nominated for rtm... and if folks have an idea for some high reward low risk items... it might go to rtm-need-info rather than rtm-minus. We'd love to go faster, as would any app. We seem to be over the hump for basic usability, although no one in this bug has called us snappy. IMO, I'm more concerned that we stabilize Mac as much as possible, and focus on other performance issues that are probably more significant at this point.

Sorry, but we already triaged this, and it is rtm-. Given how little time is left, we have to focus on higher-profile defects. If anyone has an improvement for this, please attach a patch to the bug, let us know, and we will consider it.

Did a profile. (I was in a long meeting today.) Here's what I discovered. Looked a new window creation from the XUL cache. 58% of the time is spent in nsXULDocument::ResumeWalk(). This breaks down as follows. ("Overall" numbers adjusted to reflect total time of opening new window, not percentage of ResumeWalk().) - About 35% (20% overall) of that time is spent in the initial reflow. - 36% of the time (7% overall) is spent in 57 calls to nsXBLService::LoadBindings(). 60% goes to nsXBLBindings::InstallProperties() (mostly spent in 11 calls to nsJSContext::EvaluateString()), 30% to nsXBLBinding::GenerateAnonymousContent() (mostly spent in 57 calls to nsXMLElement::CloneNode()). - 14% of the time (3% overall) is spent in 22 calls to nsPresContext::ReParentStyleContext(). - About 25% (15% overall) is spent in 22 calls to nsXULDocument::LoadScript(). - Half that time (7% overall?!?) winds up in two calls to nsXULElement::GetScriptObject(), apparently retrieving the -moz-binding property value from the nsIDOMCSSStyleDeclaration. This ends up down in the bowels of the style system resolving the style on something. Should look into this. - About 17% (10% overall) is spent in nsXULDocument::ResolveForwardReferences(). - 50% of the time is spent in nsXULDocument::AddSubtreeToDocument(). - 25% of the time (2.5% overall) is beneath that: spent in nsXULDocument::CheckBroadcasterHookup() hooking up broadcasters. - 16% of the time (1.6%), still beneath AddSubtreeToDocument(), is spent in 19 calls to nsXULTemplateBuilder::CreateTemplateAndContainerContents(). This is to be expected. - Slicing this a different way, 62% of the time (6% overall) is spent in 1,014 calls to nsXULElement::SetAttribute(). This is dominated (60%) by 290 calls to nsXULElement::EnsureSlost() (about 4% overall). - 30% of the time (3% overall) is spent in nsXULElement::SetDocument(). Strangely, we have 183 calls to SetAttribute() here that dominate the calls: ah, it's the "reset" hackery that forces event handlers to get re-compiled. - 6% of the time is spent in two calls to nsJSContext::InitContext().

Hey Chris, is it possible to see the numbers for the mail compose window, or perhaps the mail 3-pane?

kandrot has data on the mail 3-pane.

Any news? This is the main perf issue...

This bug was mentioned on 11/15/2000 by Jim Thomason at http://www.macintouch.com/netscape6.html: Openning new windows is mind numbingly slow, taking in excess of 15 seconds most of the time. Sometimes, new windows cannot be openned at all, especially with the command-n short cut. File->new navigator works more consistently, but is also known to be problematic.

I find performance "acceptable" on a 350Mhz G3. I can definitely see this being a major problem on a slower machine. A recurring theme of the macintouch thread is that page rendering is zippy, but the program "feels" slow which is a huge turnoff. Waiting even 1s for a window to open seems like an eternity when IE or NN4.7 do it in a fraction of a second... same goes for menus.

is there still someone working on this? the latest nightlies are taking 5-10 secs for creating a new window, and thats on a P3-550 with 256MB. And within this time Mozilla seems completly blocked :-/

Try out with a new profile. When I convert from NS4 I get 1-2 sec for new window, but with a clean profile they take 2 times quicker. PS The time also depends on how long mozilla was running - afret half an our and many sites visited it takes ~40Mb and more...

Eugen: Thanks, it is much faster now. Seems there were some old datas left in my directories :-) Anyway, its still not fast enough ;-)

That's a bug in itself. Filed bug 61994.

i'm not making any progress on this, and it's not priority for embedding. maybe a new owner would be better.

Bill is starting to look into this, I think...

just for information: bug 68002 is strongly connected to this bug and contains some nice profiler datas :-)

i'm obviously not looking at this anymore. someone on the perf team needs to.

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

Chris- Dave Hyatt has expressed an interest in working on this, and should actually have some spare cycles now and again. Feel free to reassign it to him if you like.

nom nscatfood: this is one of the top perf issues for end user satisfaction with the product (right after startup and page load issues.)

Okay. Since this isn't "assigned", I'm sliding it over to Hyatt/moz0.9.1

I have a patch that speeds up style resolution. Helps with new window creation and with UI responsiveness. It's over in bug #62985.

Oops. I meant bug #62895.

Haven't seen much activity on this bug lately, and saw a lot of early focus on the mac platform. ctrl-n to get a new window takes (wall clock) 6.19 seconds to show the framework (the menus, url bar, nav buttons), and an additional 3.57 seconds to show content ( the new window was loading www.mozilla.org ). as a reference, ns 4.76 displays the window framework in (again, wall clock) 1.34 seconds and fills in content ( www.mozilla.org) in an additional 1.72 seconds. this is on a AMD k2-400, 192 MB ram, linux 2.2.19pre17 with a mozilla nightly build id of 2001031611

rob: blakes fix for bug 72923 should have improved new windows performance too. What times to you measure now?

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

I find new window performance barely acceptable. It isn't a showstopper but it really should improve.

Bug 75672 will give us another boost here, especially when using an editor (e.g., mailcompose and composer).

taking this tracking bug for window open issues :-)

Jens-Uwe: nightly build ( id 2001042706 ) ( don't know if those come w/ or w/o debugging) . start mozilla, let things 'settle' . ctrl-n (start watch timer) . chrome comes up. ( hit 'lap' on watch: 7.41 seconds ) . page fills in ( hit stop on watch: 3.64 seconds ) total time: 11.05 same hardware and linux kernel as before so no, i don't see any improvement.

need to keep going to make this better, but moving tracking bugs off the 0.9.1 list to help reduce the list.

anybody have any progress on this bug?

this is a tracking bug for window open issues. all issues we have identified are listed as depending bugs. Several fixes are expected to land in 0.9.2

Brett: add yourself in the cc list. Every time a 49141 depended bug (see list) changes state, you 'll receive a notification from Bugzilla.

Compare bug 83421 - Window close perf on Linux.

For reference, on my K6-2 300 machine with 256Mb PC100 (iirc) RAM, on Linux, built from the tip about an hour ago (shortly before branching), new window takes a full four seconds (Classic theme). That's without hyatt's style branch, but with GCC-2.95.4 and -O2 optimisation.

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

I would like to nominate this for nsenterprise+ This is a really major issue for the Enterprise Client Calendar team. We are seriously considering not using XUL and CSS for any of our UI (just building it directly on gFX) because of this one bug. (Yes, we know how much flexibility we are giving up by doing this.) Opening a new window for a relatively simple dialog box should take < 1 sec on a slow machine for the user to at least see that the window is opening, and < 2 sec until they can start using the dialog box. We need to know ASAP that this bug will _definitely_ be fixed (in the sense of seeing major, more than 2-fold, improvements over current performance) before the end of this year (when we hope to beta), otherwise we are going to have to start down the path of rolling our own solution to doing UI, rather than relying on XUL and CSS.

RogerD I hope your target times are off by an order of magnitude. Any reasonable dialog should take less than 0.2 seconds to appear (on second try when all is cached). A new blank navigator should take less than 1 second. This is worst case (P200, assuming enough RAM, idle, not swapping). On something like P2 400 the dialogs should take << 0.1 and new window should take < 0.25. This would make moz competitive with 4.x (and galeon/k-meleon) I think this needs about factor of 3x or 4x improvement.

I have to agree, of course.

While everyone else is chiming in with utterly useless comments, I'd like to put in my vote that I think new window time should be no faster than 3 seconds. Novice users will get confused with windows popping up too quickly. It will startle them and leave a bad impression of our application. Furthermore, if the computer takes a long time to do something, users will believe that the computer has to think about it and can therefore feel superior to their computers. "Ha!" they'll think, "You're not so smart after all you...you...smarty-pants!" We are empowering users, allowing them to regain their lost sense of intellectual superiority in this age of wrist-watch televisions and flying cars. I will fight to the death any attempt to fix this bug or any patch that makes new window time faster.

Rock on, brother Pink.

I would like to retract my proposal of nsenterprise+ for this bug and those it depends on. We (the enterprise calendar client group) now have some detailed timing data, which can be found at: http://jazz.mcom.com/users/srim/publish/XUL_Performance.htm In summary, using the 0.9.1 release version (the debug version is a lot slower) of Mozilla on a 266MHz P2 (just a little faster than the 233 MHz P1 that mozilla.org quotes as the minimum system requirements): Open a small "Hello World" XUL window defined in a static file (from onClick of button to open to onLoad of page): 1.03 sec first time, 0.08 sec subsequent times. Open a large complex XUL window defined in a static file (from onClick of button to open to onLoad of page): 1.11 sec first time, 0.55 sec subsequent times. [Note that the onLoad of the XUL page happens before rendering starts, not after it is finished as it would for an HTML file, so the above times are less than the actual time we are keeping the user waiting. Attempts to measure the time from clicking the button to page rendering finished with a stopwatch have suggested that a) the additional time is no more about 20% of the figures given above, and b) it's realy hard to get accurate timings with a stopwatch.] ~0.1 sec to open a trivial page on a slow machine is quite respectable. ~0.6 sec to open a complex page could definitely be improved, but is definitely within the < 1 - 2 sec usability criterion I proposed above. So I would say that while XUL window opening time could still do with improvment, they are not so bad that is inherently impossible to build an enterprise-quality product on top of XUL (some of the windows in mailnews are clearly too slow for enterprise use at the moment - e.g. the compose window which is what originally got use concerned about this, but that's a separate bug specific to mailnews), and thus the nsenterprise+ tag is not justified (at least not on Windows - we havn't done any Mac timing). [It remains to be seen if I can convince my manager of the above - he's still really worried about the performance and reliability of XUL - but I'm now convinced.]

Note that new window time will see several substantial improvements in the next 6 months, so if these times are borderline for you, it's a safe bet that the times will be improved enough so that they're within a comfortable range.

New window performance is still way too slow relative to other browsers, and also from an absolute point of view. For me, this is the no. 1 performance issue. Why doesn't the bug has a target milestone although the keywords contain mozilla 0.9 and mozilla 1.0. It also has 78 votes now - one of the bugs with the highest number of votes. Could you please reconsider it for Mozilla 0.9.3?

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

niv_twig: this is a tracking bug, so the work is not done here but in the bugs this one depends on (see header). If you keep the mouse a moment on the bug number you get the title and the status of the bug. Most of them are "assigned", which is a good sign...

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

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

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

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

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

I added a simple benchmark. (my .js is not very good) My times: (Linux) NS 4.x: between 400 and 500 ms Mozilla: between 1500 and 1800 ms So, about 4x slower. Mozilla also seems to get slower much faster if many window are opened. (moz took 2.1 seconds with about 20 windows open, 4.x took just over 0.5 sec with about 30 windows open). It would be great if someone started measuring the times daily on different platforms and posted nice graphs to .mozilla.performance like it is done for starting and page loading times. It would also be nice to have back/forward and window.close performance.

mozilla with 10 windows: 776 netscape 4.77 with 1 window: 3276 i dont think your program is accurate for me :) (i did it 2 times)

This test is only reliable when the browser is offline (otherwise, network connection time gets involved). My times are: Mozilla 0.9.2: 1020. IE 5.5: 260. NS 4.7: 190. I tested with only one open window, on Win98, Pentium 450, 128MB RAM.

This bug blocks bug 71066 - Mozilla 1.0 performance tracking bug list. Therefore its target milestone should be less or equal mozilla-1.0 but 0.9.3 would be better :). I know that this is a tracking bug for other bugs, but even if you don't set the target milestone for this bug, all the bugs that it depends on should have a target milestone less or equal mozilla-1.0 . However, even some of the ASSIGNED bugs that this bug depends on have target milestones of Future or none. I think this should be fixed. Another issue: since the last time Mike Pinkerton profiled New Window performace a year ago, there have been many changes and improvements. It would be nice if someone could post here current profiling data to see what is taking the time.

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

I have a AMD k6 300mhz 64mb ram but I read my post of bug(91433) is duplicate of bug. yeah ok, I have 49.5Mb free RAM... mozila is loaded all to memory winout use the swap file... in my computer whem i open new windows or open the page. the processor usage for mozilla get 98%, and in other intel processor with 64Mb and 300mhz, get about 70%.. I get 70% if I move mouse on butons winout click. in use the mozilla dll's fine as K'melion the brosers run very fast... I get 14sec to open a new window... and 5 to close and the back window of mozilla appear netscape 6 in varios operations not happened this. to pass mouse on buttons, to open preferences, etc.. But I like more Mozilla. Suns

Comparing to Pink's long-ago figures, nothing has changed much. ResumeWalk still takes 50% of the time, 2/3 of that in adding the frames. nsXBLService::LoadBindings is about 20%, which is the majority of the nsCSSFrameConstructor::ContentAppended time. nsDocShell::CreateContentViewer is about 10%, most of it in JS garbage collection (nsJSContext::GC) Lots of XBL and XUL 6% in CSSRuleProcessor::RulesMatching 13% in nsXULElement::SetAttr, much of which is in FrameManager::ReResolveStyleContext 9% in nsXULDocument::ResolveForwardReferences 8% in _js_LookupProperty

> 8% in _js_LookupProperty Odd: the costs here are not likely to be in the short prototype chain search, at each step of which an O(1) hash table lookup is done. I would expect that the JSClass.resolve hook's implementation, which winds up in dom/src/base/ nsDOMClassInfo.cpp and perhaps nsGlobalWindow.cpp code, should pop out. Can you say what descendents dominated? /be

http://bugzilla.mozilla.org/attachment.cgi?id=47749&action=view#2365 Direct hits, total hits, name: 3 57 _js_LookupProperty 4 36 XPC_WN_Helper_NewResolve 0 18 nsWindowSH::NewResolve 0 4 JS_ValueToId 0 14 XPC_WN_ModsAllowed_Proto_Resolve 3 10 DefinePropertyIfFound 0 3 XPCWrappedNative::HandlePossibleNameCaseError The rest devolves into fanout in small amounts. I only put in the high-hit routines. There are a few oddities (like the HandlePossibleNameCaseError), but none that are likely to cause the real issues here.

In an optimized build on Linux I'm seeing 5.2% in js_LookupProperty (note that I'm using brendan's jsdhash patch -- that may make a difference, although I don't think that much). I'll attach a profile containing only stacks that include js_LookupProperty.

Randell, you should avoid profiling DEBUG builds. The leading underscore in _js_LookupProperty, and the DEBUG-only XPCWrappedNative::HandlePossibleNameCaseError, are tell-tales. /be

Sorry, that was the build I had. It's debug -O2. I'll make another non-debug build

from Randell Jesup's posting at 2001-08-30 : > Comparing to Pink's long-ago figures, nothing has changed much. ResumeWalk > still takes 50% of the time, 2/3 of that in adding the frames. I am not very knowledgeable in mozilla's code, so maybe this question is stupid: Why Building frames takes so much time on an empty page (about:blank)? There should be a very small number of frames in this page, isn't it?

Out of 367 hits: 10% 2 36 js_LookupProperty 1 19 XPC_WN_Helper_NewResolve 15 nsWindowSH::NewResolve 7 nsWindowSH::GlobalResolve 5 JS_DHashTableDestroy 4 JS_NewDHashTable 9% 0 32 nsXULDocument::OverlayForwardReference::Resolve(void) 19 nsXULDocument::AddSubtreeToDocument(nsIContent *) 13 nsXULDocument::OverlayForwardReference::Merge 12% 41 GlobalWindowImpl::SetNewDocument(nsIDOMDocument *) 39 nsJSContext::GC 43 JS_DHashTableEnumerate 40 gc_root_marker <various JS GC stuff> 6% 20 nsScriptSecurityManager::GetObjectPrincipal 6% Note that SearchTable was the #1 flat hit 3 20 JS_DHashTableOperate 17 17 SearchTable Around 8% (maybe more) resolving style 18% 0 58 nsXBLBinding::InstallProperties

I decided to profile (with jprof, on Linux) opening as many windows (with the homepage preference set to blank page) as I could in a minute (well, not quite, since I paused a few times to let things catch up). I then used jprof's includes and excludes to separate the profile into pieces. I split it up as follows, where each item doesn't count any time spent within one of the items above it that was also within it. (I tried to select high-level operations rather than low-level things such as Atom refcounting or string copying, even though it is possible to find a general solution to some of those low-level problems.) The profile was a realtime profile, except I exclude from the total time spent in poll (which is generally time waiting for events in the event loop) but not time spent in select (which is generally time waiting for the X server). Note that some of the things in this profile are toolkit-specific, and probably aren't nearly as bad on Windows or Mac. The main changes in my tree that might help performance are brendan's changes in bug 81847. 1) 6.0% of the total was spent within nsJSContext::CompileFunction, all called from nsXBLBinding::InstallProperties. Will XBL brutal sharing fix this? (See bug 70647.) 2) 4.8% of the total was spent within RDFContainerImpl::AppendElement, all of which was called from nsWindowMediator::RegisterWindow. This is due mainly, I think, to O(N^2) (or worse?) algorithms in RDF code. They show up more painfully in other cases (such as when closing windows and in some of the search code that kicks in when a bugzilla query finishes loading). However, as far as new window time is concerned, this is relatively minor since I think it shows up mainly because I was opening around 100 windows. 3) 8.5% of the time was spent in selector matching and surrounding code (everything within StyleSetImpl::WalkRuleProcessors). Of this, 1.1% of the total (12.9% of this time) was spent in CSSRuleProcessor::GetRuleCascade, which is computing data that could probably be "brutally shared". Many other parts of this code have already been heavily optimized, although it could probably be optimized more by a significant redesign (as I suspect it's getting close to the point where a significant part of the time is in function call overhead, although I could be wrong). 4) 5.7% of the time was spent painting (within nsViewManager::RenderViews), of which 3.4% of the total was spent in nsImageGTK::DrawTile. Slightly more than 2/3 of the time in DrawTile was spent in gdk_gc_new_with_values, and almost all of the rest of the DrawTile time was spent in gdk_draw_rectangle. 5) 3.9% of the time was spent in the stack: gtk_selection_convert nsClipboard::GetTargets nsClipboard::HasDataMatchingFlavors nsPlaintextEditor::CanPaste nsPasteCommand::IsCommandEnabled nsControllerCommandManager::IsCommandEnabled nsEditorController::IsCommandEnabled 6) 3.4% of the time was spent in GTK event loop code (within gtk_marshal_NONE__NONE) 7) 8.3% of the time was spent within nsXULDocument::ResolveForwardReferences. Within this, 1.4% of the total was in nsXULElement::GetAttr. 8) 3.5% of the time was spent in Reflow (within ViewportFrame::Reflow) 9) 2.2% of the time was spent focusing the URL bar (within nsHTMLInputElement::Focus). Within this, 0.6% of the total was spent within nsJSContext::CompileEventHandler, most of which was called from nsXBLPrototypeHandler::ExecuteHandler. Will XBL brutal sharing help this? 10) 2.8% of the time was spent giving focus to some other XUL element. 0.9% of the total, within this, was spent within nsXULElement::SetAttribute (called from JS). 11) 16.5% of the time was spent within *other* things within nsXBLService::LoadBindings. (How much of this will be helped by XBL brutal sharing?) 12) 1.6% of the total time was spent within JS garbage collection, mostly in the mark phase. 13) 8.3% of the total time was spent within *other* things in frame construction. Within this: 2.2% of the total was spent within nsXULContentBuilder::CreateContents 1.5% of the total was spent within nsImageBoxFrame::UpdateImage 1.2% of the total was spent within nsStyleContext::GetStyleData 4.8% of the total time (not counting the time also categorized above) was spent within js_LookupProperty 0.7% of the total time was spent within nsJSContext::CompileEventHandler (called from XBL code) 0.6% of the total time was spent within gdk_window_get_root_origin, called from: gdk_window_get_root_origin nsWindow::GetWindowPos nsWindow::WidgetToScreen nsWindow::GetScreenBounds nsXULWindow::GetPositionAndSize nsXULWindow::PersistPositionAndSize 0.3% of the total time was spent within gdk_events_queue, in GDK event loop code The 18.1% remaining defied any useful categorization that I could find.

david: there are lots of big (js precompile, brutal sharing) and small performance patches waiting to get in the trunk in the beginning of the 0.9.5 cycle. what do you think about rerunning your test once these patches are in and stabilzed for a few days?? In bug 68002 you can find simple html code to open 50 windows, so this measuring can be automated to give more reliable results. anyway, looks like there is no real big fish but several small ones :-/

I just added a dependency on 81847, which is a hashtable perf fix (SearchTable shows up prominently in the jprofs of window.open). Results are in that bug, but basically it appears to cut about 4.4% from window open time(!) SearchTable goes from 17 direct hits to 3. I have a jprof with the patch applied; if anyone really wants it I can email or put it up here. I didn't notice many other significant differences; the biggest benefit at a higher level was to nsScriptSecurityManager::GetFunctionObjectPrincipal, which dropped from 21 to 12.

Is each window run in a separate thread or process? Or does one process try to manage all windows? It looks to me that I see windows interfering with each other big time. I watched my cpu sit idle for over 5 seconds while one window was loading and another was closing.

Generally one thread handles them.

That's a recent jprof post-XBL landing (and post brendan's hash fix that saved ~4.5%). I haven't compared it in detail yet, but I did notice that we spend a lot of our time (13%!) in GC, invoked from nsGlobalWindowImpl::SetNewDocument(). We appear to force a GC on every window open. This is from a checkin by Brendan from 10/2000 or so.

GC on window open is bug 42321.

Removing the forced GC from nsGlobalWindowImpl::SetNewDocument (admittedly a hack) produced noticably faster opening (sorry, no stopwatch times) and a reduction in the number of jprof hits (total) of >11%. (JS_GC went from 13.x% to 1.x% of the total). Brendan, do we need to force GC there? CVSBlame nominated you for adding the forced GC in SetNewDocument. Adding brendan to the CC list

rjesup: my change from 2000/01/08 merely prepended :: to JS_GC in the call to that function (beware quick use of cvsblame or cvs annotate to pin the tail on this donkey ;-). The sad history of "too much time spent in JS GC" is detailed in bug 42321 and the now-fixed bug 49816. From the latest profile's fan-out from js_GC being dominated by JS_DHashTableEnumerate, it seems we have a lot of GC roots. Maybe there is a way to reduce the number of roots, by guaranteeing liveness without a root, by consolidating redundant roots (if any). I'll measure. Of course, we need not call ::JS_GC() (a forced, global GC) every time we SetNewDocument. First, we have to rid the code of semantic actions wrongly controlled by finalization, instead of being done by mandatory/timely control flow protocols. Second, we could use JS_MaybeGC (we might then want very much to fix bug 66381). /be

I checked - changing this to a MaybeGC call produces the same benefits. However, dbaron/brendan imply that we must force a GC on page transitions. Can someone quantify a reason for this? The referenced bug (42321) doesn't go into the details. Brendan mentions some, but there's no bug on this part of it? Do we really have code that depends on a GC on page transitions?

I suspect that the main thing that depended on GC happening during page transitions was fixed with the fix for bug 80203. However, I haven't tested it. Why don't we discuss this further on bug 42321?

i believe bug 93547 (Memory leak after opening multiple browser windows) may be related. i have posted some info there and more bugs that are similar. http://bugzilla.mozilla.org/show_bug.cgi?id=93547 phil

I would like to advertise bug 111141 (surfer's wishlist). I think people who often open new windows would like the feature described there, and when appropriate use it as an alternative.

It occurred to me that it might be kind of useful for tracking this bug (especially across different platforms, since for example new window time is a bigger problem on Linux than Windows) if the browser tracked new window opening time. Right now, when loading a page, the time in 1/1000ths of a second it took is shown at the bottom -- this is really useful for tracking page loading times. It would be pretty neat if a new window showed the time it took to create in the status bar. A timer could be started when the new window command is detected (i.e., ctrl-N or the File/New Nav Window is selected) and the total time shown once the "page" (i.e. the 'about:blank') is loaded. Unrelated, but I suppose something similar could be done for startup time, only with the timer started as soon as possible after the browser is fired up. It'd help people gather statistics for new milestones and nightlies more quickly, allow easier cross platform comparisons, and make it easier to try other things (like see how long the 20th window takes to create, or how long a new window takes after several hours of browsing versus a "fresh" browser) which could help shed light on problems, and possibly lead to some fresh ideas for improvements. So far all the timings I see listed are with a stopwatch, or with multiple window opens averaged. New window opening time is definitely still a problem on Linux, but it isn't so slow that a stopwatch is going to tell you accurately if a fix that results in 5-10% improvement is checked in. Hopefully this would be really easy to do....if it isn't, then just ignore this. I just think that if it is easy to do, the gain in information would be worth the time one of the coders spends on this.

A note on measuring window open time. The test that tinderbox uses is located in http://lxr.mozilla.org/seamonkey/source/xpfe/test/winopen.xul. Anybody can run this test using the following (this is Win32; there's an equivalent on Linux, not sure about Mac): mozilla -P profile -chrome "file:///C|/mozilla/xpfe/test/winopen.xul" >log This will run the test and dump info to the file "log". I've recently enhanced that test so that you can customize it somewhat (see the associated .js file for details). For example, you can use this: mozilla -P profile -chrome "file:///C|/mozilla/xpfe/test/winopen.xul?close=0" to cause the test window to remain up (so you can re-run the tests). Anybody working specifically on window-open time should be using that test to quantify their efforts. Theoretically, any improvements you see on your machine will result in a comparable improvement, percentage-wise, on the Tinderbox test results (modulo platform-specific issues related to your work).

Bill- Do we have that note, or a link to it, published somewhere where everyone will see it, and can find it again?

I'll get a page with that info on mozilla.org, get a link to it somewhere in the "performance tools" area there, and have Chris McAfee put a link to it on the page generated by Tinderbox. I've opened bug 118898 to remind me to do that.

I'm interested in trying out Bill Law's winopen.xul script for my own amusement to track progress on window opening, and possibly improve upon it to track a few other things of interest (window close time, window open/close time with 'x' windows already open, etc.) I don't know javascript & XUL, but I should be able to figure out enough to modify what's already there to do these things. But I can't get started, I call mozilla -chrome winopen.xul and it just opens a window and sits there. I figured out that I could put winopen.xul, winopen.js and child-window.html in the chrome directory so that at least mozilla will find winopen.xul without it having to be in the current directory, but apparently that's not good enough winopen.js, I don't know where that needs to go to make it work. I'm trying this on Linux, using the 0.9.7 talkback (installer) install. Since shift-left button wanted to download these files off LXR as 'html' files I had to cut and paste them and remove the line numbers, I'm pretty sure I did it right but if what I've done so far "should work" I'll go back and try to grab them again and be more careful (maybe NS 4.x will download them correctly if it isn't a server side content-type issue)

You need to provide a 'file://' url as the argument to '-chrome', e.g., ./mozilla -chrome file:///path/to/files/winopen.xul LXR will serve the HTML-ized version of any file, by design. You can either copy/paste the content from a browser window showing these files and remove the cruft from that, or, with CVS, you can (much easier) just checkout the files directly: 'cd somedirectory; cvs co mozilla/xpfe/test'. (First you need to set CVSROOT and do a cvs login if you haven't used cvs before; see http://www.mozilla.org/cvs.html for details).

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

Just thought I would comment that the new window performance is improved in build 0.9.9 + (2002030808) over the milestone release of 0.9.8. Still room for improvement in 1.0, but it is better.

moving tracking/meta bugs out of milestone pools.

This is *very* much improved in 1.0RC1 compared to earlier milestones, on Liunx at least, in my subjective Opinion. It "feels" as fast as 4.7x now.

New window performance seems to have gotten worse in 1.0rc1 on Mac OS X. On a G3 500Mhz, it takes about 9 seconds to display the first window after the mozilla splash disappears. Using File->New->Navigator Window, it takes about 18-20 seconds for a window to show up, either with all windows closed, or with one open. .9.9 was much quicker for these operations. G3 500 Mhz, Mac OS X 10.1.4, 256 MB ram. Build 2002041712.

quick note re: my mac os x post. 1.0 rc3 seems to have fixed this. Back to 0.9.9 speeds, or better.

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

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

adt: removing nsbeta1 nomination; nominate bugs indiviually as appropriate.

hasn't the goals of this been achieved?

This bug (slow window opening on Linux in some circumstances) is still quite apparent. I'm running a stock Fedora Core 6 (x86), using: Firefox 1.5.0.7; Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061011 Fedora/1.5.0.7-7.fc6 Firefox/1.5.0.7. It's most obvious after I have a dozen windows open, many of which have five to ten tabs inside. At that point, opening a new window (Ctrl-N, or other ways such as "Open Link" from a gterm window) takes about 14 seconds (I just measured). During that time, the CPU meter is pegged (I'm running on an Athlon 64 X2, with 1GB of RAM, so it pegs to 50% -- all of one CPU core -- rather than 100%), and other windows won't refresh. The bug is so predictable that once it's gotten into this state, I end up shunning the creation of new windows. I never hit Ctrl-N, I just open more tabs. When opening URLs from a terminal window, I "Copy Link Address", open a new TAB, and paste the URL into it. That runs nice and fast. Every once in a while I'll encounter a nasty web site that thinks it knows better than me whether a new window should open when I click on a link, then Mozilla freezes and I say, "Oh, no, caught again...". Closing many many windows and tabs does not eliminate the bug. For what it's worth, I took a gdb stack trace during one such CPU-busy hang, and here's what I got: ...after attaching, I got pages and pages of "Reading symbols from ..." messages for the various shared libraries... [Thread debugging using libthread_db enabled] [New Thread -1208513792 (LWP 3247)] [New Thread -1541424240 (LWP 20644)] [New Thread -1282913392 (LWP 8806)] [New Thread -1221108848 (LWP 3249)] [New Thread -1210618992 (LWP 3248)] ...lots more Reading symbols messages... 0x4c3e27b2 in g_slice_free_chain_with_offset () from /lib/libglib-2.0.so.0 (gdb) bt #0 0x4c3e27b2 in g_slice_free_chain_with_offset () from /lib/libglib-2.0.so.0 #1 0x4c3e3711 in g_slist_free () from /lib/libglib-2.0.so.0 #2 0x4c7a84a4 in pango_layout_iter_get_char_extents () from /usr/lib/libpango-1.0.so.0 #3 0x4c7aa305 in pango_layout_get_line () from /usr/lib/libpango-1.0.so.0 #4 0x0068420a in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgfx_gtk.so #5 0x0068500c in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgfx_gtk.so #6 0x0067ac45 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgfx_gtk.so #7 0x0067a8ae in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgfx_gtk.so #8 0x010b0667 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #9 0x010b633b in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #10 0x0109340d in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #11 0x010654c0 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #12 0x01065970 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so ---Type <return> to continue, or q <return> to quit--- #13 0x01065be1 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #14 0x01065e24 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #15 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #16 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #17 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #18 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #19 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #20 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #21 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #22 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #23 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #24 0x01065ce3 in NSGetModule () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #25 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #26 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #27 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #28 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #29 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #30 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #31 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #32 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #33 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #34 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #35 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so ---Type <return> to continue, or q <return> to quit--- #36 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #37 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #38 0x01138bcd in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #39 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #40 0x0114cef8 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #41 0x0114b4d3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #42 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #43 0x0114eaf1 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #44 0x0115063f in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #45 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #46 0x01142be3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #47 0x01146792 in NSGetModule () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #48 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #49 0x01148dd2 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #50 0x01149cd7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #51 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #52 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #53 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #54 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #55 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #56 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #57 0x01138bcd in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #58 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so ---Type <return> to continue, or q <return> to quit--- #59 0x0114cef8 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #60 0x0114b4d3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #61 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #62 0x0114eaf1 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #63 0x0115063f in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #64 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #65 0x01142be3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #66 0x01146792 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #67 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #68 0x01148dd2 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #69 0x01149cd7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #70 0x0106ab75 in NSGetModule () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #71 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #72 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #73 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #74 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #75 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #76 0x01138bcd in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #77 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #78 0x0114cef8 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #79 0x0114b4d3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #80 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #81 0x0114eaf1 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so ---Type <return> to continue, or q <return> to quit--- #82 0x0115063f in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #83 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #84 0x01142be3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #85 0x01146792 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #86 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #87 0x01148dd2 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #88 0x01149cd7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #89 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #90 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #91 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #92 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #93 0x010690de in NSGetModule () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #94 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #95 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #96 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #97 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #98 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #99 0x0106ab75 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #100 0x01064cf7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #101 0x01065ce3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #102 0x010663ab in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #103 0x010690de in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #104 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so ---Type <return> to continue, or q <return> to quit--- #105 0x01084b84 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #106 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #107 0x0108137e in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #108 0x01081722 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #109 0x010820bd in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #110 0x0106fdf3 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #111 0x010bb191 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #112 0x01054d99 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #113 0x010499ed in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #114 0x0104ac1d in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #115 0x0104ac60 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #116 0x4cf0cd17 in nsIThread::SetMainThread () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #117 0x4cf0cdd8 in nsIThread::SetMainThread () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #118 0x4cf08c01 in PL_HandleEvent () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #119 0x4cf08e8a in PL_ProcessPendingEvents () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #120 0x4cf0a6b7 in nsAutoMonitor::NewMonitor () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #121 0x00ddc05f in ?? () from /usr/lib/firefox-1.5.0.7/components/libwidget_gtk2.so #122 0x00227fbb in ?? () from /usr/lib/firefox-1.5.0.7/components/libnsappshell.so #123 0x002229a0 in ?? () from /usr/lib/firefox-1.5.0.7/components/libnsappshell.so #124 0x0018203c in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libtoolkitcomps.so #125 0x006fcd07 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libembedcomponents.so #126 0x006fa0ff in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libembedcomponents.so #127 0x012c4fa2 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so ---Type <return> to continue, or q <return> to quit--- #128 0x012c0166 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #129 0x4cf1fbe1 in XPTC_InvokeByIndex () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #130 0x00a4b43f in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libxpconnect.so #131 0x00a4f119 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libxpconnect.so #132 0x4b883aa7 in js_Invoke () from /usr/lib/firefox-1.5.0.7/libmozjs.so #133 0x4b87e641 in js_AllocStack () from /usr/lib/firefox-1.5.0.7/libmozjs.so #134 0x4b8833aa in js_AllocStack () from /usr/lib/firefox-1.5.0.7/libmozjs.so #135 0x4b853386 in JS_EvaluateUCScriptForPrincipals () from /usr/lib/firefox-1.5.0.7/libmozjs.so #136 0x012b0a9c in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #137 0x012ebae0 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #138 0x012ebde9 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #139 0x012ebf92 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libgklayout.so #140 0x003c65b7 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so ---Type <return> to continue, or q <return> to quit--- #141 0x003c7fd8 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so #142 0x003ac541 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so #143 0x003b2987 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so #144 0x003b5dee in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so #145 0x003bee55 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so #146 0x003c084f in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so #147 0x003bd67e in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libdocshell.so #148 0x4cf08c01 in PL_HandleEvent () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #149 0x4cf08e8a in PL_ProcessPendingEvents () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #150 0x4cf0a6b7 in nsAutoMonitor::NewMonitor () from /usr/lib/firefox-1.5.0.7/libxpcom_core.so #151 0x00ddbbfe in ?? () from /usr/lib/firefox-1.5.0.7/components/libwidget_gtk2.so #152 0x4c3f494d in g_io_channel_unix_get_fd () from /lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #153 0x4c3cb342 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #154 0x4c3ce31f in g_main_context_check () from /lib/libglib-2.0.so.0 #155 0x4c3ce6c9 in g_main_loop_run () from /lib/libglib-2.0.so.0 #156 0x4c8f9be4 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #157 0x00ddbfeb in ?? () from /usr/lib/firefox-1.5.0.7/components/libwidget_gtk2.so #158 0x00181f86 in NSGetModule () from /usr/lib/firefox-1.5.0.7/components/libtoolkitcomps.so #159 0x0804f66f in __cxa_pure_virtual () #160 0x0804ab90 in __cxa_pure_virtual () #161 0x4c20ef2c in __libc_start_main () from /lib/libc.so.6 #162 0x0804aae1 in __cxa_pure_virtual () (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Detaching from program: /usr/lib/firefox-1.5.0.7/firefox-bin, process 3247

john: can you please use a recent edition of firefox? The 1.5 series is pretty old already. You can download the nightly here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

john: can you please test a recent edition of firefox? The 1.5 series is pretty old already. You can download the nightly here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

I haven't measured 1.5.x, but new window performance actually feels slower on 2.x. I just measured the elapsed time between pressing ctrl-N and a new window appearing at over 10 seconds (Ubuntu Dapper, FF 2.0.0.2), which is pretty long for an unloaded, not-swapping system.

This bug is from year 2000, a time when opening *any* window - *any*, for everybody, even right after start - took maybe 5 seconds. See comment 3, 11 and 13. The bug here is a core bug about window open, XUL etc., and to generally optimize the window open performance The problem you cite seems to be different. Windows open quickly for me, even if I have quite a number of Firefox windows open. It seems to be related to number of tabs or number of open pages, so it's probably a Firefox bug, not Core. it seems there's some particular code bit which does something stupid and slow, not a general problem, and not about Core either. Please file a new bug.

(In reply to comment #158) > This bug (slow window opening on Linux in some circumstances) is still quite > apparent. I'm running a stock Fedora Core 6 (x86), using: Firefox 1.5.0.7; > Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.7) Gecko/20061011 > Fedora/1.5.0.7-7.fc6 Firefox/1.5.0.7. > > It's most obvious after I have a dozen windows open, many of which have five to > ten tabs inside. At that point, opening a new window (Ctrl-N, or other ways > such as "Open Link" from a gterm window) takes about 14 seconds (I just > measured). During that time, the CPU meter is pegged (I'm running on an ... ... > The bug is so predictable that once it's gotten into this state, I end up > shunning the creation of new windows. I never hit Ctrl-N, I just open more > tabs. When opening URLs from a terminal window, I "Copy Link Address", open a > new TAB, and paste the URL into it. That runs nice and fast. Every once in a > while I'll encounter a nasty web site that thinks it knows better than me > whether a new window should open when I click on a link, then Mozilla freezes > and I say, "Oh, no, caught again...". > > Closing many many windows and tabs does not eliminate the bug. ... There are some open (and closed, and WONTFIX) bugs for windows not opening into tabs. Though not the solution to this problem, fixing these other bugs would help in the workaround situation.

When i start Firefox 2.0.0.3, opening windows is pretty fast. After a while it goes slow. Along with everything on this computer that needs to allocate memory. As comment 162 seems to indicate, the following bugs are more important than this one. All open Mozilla memory leak bugs: https://bugzilla.mozilla.org/buglist.cgi?keywords=mlk&resolution=--- By severity: https://bugzilla.mozilla.org/buglist.cgi?keywords=mlk&resolution=---&order=bugs.bug_severity With about 60 tabs open in 4 Firefox 2.0.0.2 windows on K/Ubuntu 6.10 with 440 MB RAM and these extensions: Add Bookmark Here 0.5.5 Bookmark Duplicate Detector 0.6.3 Change 0.0.0.7 [DISABLED] Clean And Close 2.0 Download Statusbar 0.9.4.5.1 [DISABLED] Extended Statusbar 1.2.5 Extension Manager Extended 2.6 Firebug 1.01 Firefox Showcase 0.9.2.2 Image Zoom 0.2.7 [DISABLED] Leak Monitor 0.3.6 Mozex 1.9.5 Nightly Tester Tools 1.2.1 Paste and Go 2 0.8 Referrer History 1.0.3.5 Session Manager 0.5.3.2 SwitchProxy Tool 1.4.1 Translate 0.6.0.8 Web Developer 1.1.3 It takes about 4 days before i have to kill -9 it.

(In reply to Ben Bucksch (:BenB) from comment #162) > This bug is from year 2000, a time when opening *any* window - *any*, for > everybody, even right after start - took maybe 5 seconds. See comment 3, 11 > and 13. The bug here is a core bug about window open, XUL etc., and to > generally optimize the window open performance adjusting summary accordingly - assuming this bug is still wanted, since it's original purpose seems to have been fulfilled.

> original purpose seems to have been fulfilled Agreed. Marking FIXED. Thanks to all who worked on this. This was hard and important, and you succeeded. Without it, Firefox would never have succeeded.