Closed Bug 49141 Opened 24 years ago Closed 10 years ago

New window performance

Categories

(Core Graveyard :: Tracking, defect, P2)

Product:
Core Graveyard
Component:
Tracking
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: sfraser_bugs, Assigned: chofmann)

References

(Depends on 1 open bug)

Details

(Keywords: meta, perf, topperf, Whiteboard: [nav+perf][Snappy:P3])

Attachments

(8 files)

Screenshot from instrumentation sdk of 2nd browser window
40.90 KB, image/jpeg
Details
Open new window benchmark
488 bytes, text/html
Details
opens 20 about:blank windows. Very stupid.
654 bytes, text/html
Details
jprof of 20 window.open's of about:blank dual PIII-450's Linux
645.32 KB, text/html
Details
Profile of time within js_LookupProperty, opening new windows
135.20 KB, text/html
Details
jprof of non-debug -O2 build
411.42 KB, text/html
Details
opening a new window (linux - hacked eazel profiler) BIIIG.html.zip
1.63 MB, application/octet-stream
Details
New jprof of window open, post-XBL landing (update/build 9/17/2001 trunk)
653.97 KB, text/html
Details 
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
Keywords: nsbeta3, nsmac1, perf
Blocks: 22486
Waterson is swamped -> ducarroz
Assignee: waterson → ducarroz
No longer blocks: 22486
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.
Keywords: dogfood
This is a completely dreadful problem on unix also.
Changing platform to 'all'.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Adding bug 42321 as a factor.
Depends on: 42321
Putting on [dogfood+] radar
Whiteboard: [dogfood+]
*** 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.
Assignee: ducarroz → pinkerton
Priority: P3 → P2
> 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.
Whiteboard: [dogfood+] → [dogfood+] [nsbeta3+]
Status: NEW → ASSIGNED
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.
Target Milestone: --- → M18
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.
Depends on: 48274
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
Whiteboard: [dogfood+] [nsbeta3+] → [dogfood+] [nsbeta3+][PDTP2]
Depends on: 52108
PDT marking nsbeta3-, nominating for rtm
Keywords: rtm
Whiteboard: [dogfood+] [nsbeta3+][PDTP2] → [dogfood+] [nsbeta3-][PDTP2]
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
Target Milestone: M18 → Future
rtm-
Whiteboard: [dogfood+] [nsbeta3-][PDTP2] → [dogfood+] [nsbeta3-][PDTP2][rtm-]
Please remember that this is still [DOGFOOD+].

Nominating for mozilla0.9.
Keywords: 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.
Whiteboard: [dogfood+] [nsbeta3-][PDTP2][rtm-] → [nsbeta3-][PDTP2][rtm-]
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).
Whiteboard: [nsbeta3-][PDTP2][rtm-] → [nsbeta3-][PDTP2][rtm-][dogfood-]
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.
Whiteboard: [nsbeta3-][PDTP2][rtm-][dogfood-] → [nsbeta3-][PDTP2][rtm-]
'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.
Keywords: 4xp
Whiteboard: [nsbeta3-][PDTP2][rtm-] → [nsbeta3-][PDTP2]
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.
Whiteboard: [nsbeta3-][PDTP2] → [nsbeta3-][PDTP2][dogfood-]
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.
Whiteboard: [nsbeta3-][PDTP2][dogfood-] → [nsbeta3-][PDTP2][dogfood-][rtm-]
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.
Target Milestone: Future → mozilla0.9
Any news? This is the main perf issue...
Component: Browser-General → XP Toolkit/Widgets
Keywords: nsbeta3 → helpwanted, mozilla1.0
QA Contact: doronr → sairuh
Whiteboard: [nsbeta3-][PDTP2][dogfood-][rtm-] → [PDTP2][dogfood-][rtm-]
QA Contact: sairuh → jrgm
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.
Target Milestone: mozilla0.9 → mozilla1.0
Keywords: nsbeta1
Bill is starting to look into this, I think...
Keywords: rtm
Whiteboard: [PDTP2][dogfood-][rtm-]
Blocks: 68002
Keywords: dogfood → nsdogfood
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.
Assignee: pinkerton → chofmann
Status: ASSIGNED → NEW
*** Bug 71073 has been marked as a duplicate of this bug. ***
Blocks: 71066
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.)
Keywords: nsCatFood
Okay. Since this isn't "assigned", I'm sliding it over to Hyatt/moz0.9.1
Assignee: chofmann → hyatt
Target Milestone: mozilla1.0 → mozilla0.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.
Status: NEW → ASSIGNED
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
Depends on: 72345, 72381
Depends on: 62985, 70647, 71470, 72342, 72344, 72347
Depends on: 62895
No longer depends on: 62985
Keywords: topperf
rob: blakes fix for bug 72923 should have improved new windows performance too.
What times to you measure now?
Keywords: nsCatFood+
Keywords: nsCatFood
*** 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 :-)
Assignee: hyatt → cathleen
Status: ASSIGNED → NEW
Component: XP Toolkit/Widgets → Tracking
Depends on: 75672, 77999
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.
Blocks: 75643
need to keep going to make this better, but moving tracking bugs off the 0.9.1 
list to help reduce the list.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Blocks: 9805
Depends on: 80147
Depends on: 80208
Depends on: 78077
Depends on: 77051
Target Milestone: mozilla0.9.2 → ---
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
Depends on: 78695
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.
Depends on: 83421
*** 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.
Whiteboard: [nav+perf]
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. ***
Attached file Open new window benchmark — 

    
    

    
  
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


    
  
Depends on: 94199

    
    

    
  
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.

    
  
Blocks: 99053

    
    

    
  
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.

    
    

    
  
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?

    
  
Blocks: 104166

    
  
Depends on: 104176

    
  
Depends on: 104658
Keywords: meta

    
  
No longer depends on: 104658

    
  
Depends on: 104658

    
  
Depends on: 105333

    
  
No longer blocks: 100210

    
  
Whiteboard: [nav+perf] → [nav+perf] [Aufbau-P1]

    
  
Whiteboard: [nav+perf] [Aufbau-P1] → [nav+perf]

    
    

    
  
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

    
  
Depends on: 107900

    
    

    
  
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.

    
  
Depends on: 102992

    
    

    
  
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).

    
  
Target Milestone: --- → mozilla1.0

    
    

    
  
*** 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. 
Target Milestone: mozilla1.0 → Future

    
    

    
  
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.

    
  
Blocks: majorbugs

    
    

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

    
    

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

    
  
Keywords: nsbeta1

    
  
Depends on: 196843

    
    

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

    
  
No longer blocks: majorbugs

    
    

    
  
hasn't the goals of this been achieved?
Assignee: cathleennscp → chofmann
QA Contact: jrgmorrison → chofmann

    
    

    
  
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.

    
  
No longer blocks: 99053
Whiteboard: [nav+perf] → [nav+perf][Snappy]

    
  
Whiteboard: [nav+perf][Snappy] → [nav+perf][Snappy:P4]

    
  
Whiteboard: [nav+perf][Snappy:P4] → [nav+perf][Snappy:P3]

    
    

    
  
(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.
Keywords: helpwanted
Summary: New window performance → Optimize new window performance [meta]

    
    

    
  
> 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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Summary: Optimize new window performance [meta] → New window performance
Product: Core → Core Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: