27056 - Page load time takes twice as long as M13 on yahoo.com, my netscape

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[chriss]

On my Win98 home system with DSL connection (PII400/128MB), my.netscape.com 
loads perf is approx 1/2 of what it was with M13. On average, with a stop watch, 
here are the numbers I get for My Netscape:
 
M14 (2/8) 9.5 sec 
M13       4.0 sec
4.7       3.5 sec

This is a serious regression and we should be at M13 perf levels at least for 
beta 1.

Comment 1

[chriss]

Adding beta 1 keyword

Comment 2

[troy]

Works fine for me with latest build...

Comment 3

[chriss]

I just installed today's build on my work laptop (PII300 on LAN). I'm still 
seeing the problem. The average of 3 page loads is 4.2 sec for M13 and 8.36 
sec for M14 for My Netscape.

As another example, here's what I see on yahoo.com after loading the page 5 
times.

M13   M14 (2/9)
.88   3.57
.87   3.51
.93   3.57
.88   3.9
.93   3.51
---   ---
.89   3.612  Average

In this case M13 is 4x faster than M14

Comment 4

[chriss]

Reopening the bug. Would like more data from QA to validate what I'm seeing

Comment 5

[troy]

Re-assigning to QA

Comment 6

[chriss]

I ran today's viewer.exe on yahoo.com and page loading is taking about 3-4 sec. 
So this is consistent with what I'm seeing in apprunner.

[This is Eric Krock.] Looks like we're being too incremental; you see the 
yahoo.com home page reflow several times now. Also, look at how the "In the 
News" gray section on the right side of the page pops up after three or four 
reflows. Looking at the source, that's a deeply nested table (at least three 
levels). Here's an excerpt from the HTML: 

<td align=right valign=top bgcolor=dcdcdc width=155><table border=0 
cellspacing=1 width="100%"><tr><td align=center bgcolor=ffffcc nowrap 
colspan=2><table border=0 cellspacing=0 cellpadding=0 width=120><tr><td 
align=center><font face=arial size=2><b>In the 
News</b></font></td></tr></table></td></tr><tr><td 
valign=top><b>&#183;</b></td><td><small><a 
href="/homer/?http://fullcoverage.yahoo.com/fc/Breaking/Presidential_Election_20
00/">Forbes drops presidential bid</a></small></td></tr><tr><td 
valign=top><b>&#183;</b></td><td><small><a 
href="/homer/?http://fullcoverage.yahoo.com/fc/World/Israel___Lebanon_Conflict/"
>Israeli jets strike Lebanon</a></small></td></tr><tr><td 
valign=top><b>&#183;</b></td><td><small><a 
href="/homer/?http://fullcoverage.yahoo.com/fc/breaking/Alaska_Airlines_Crash">K
ey part of Alaska jet recovered</a></small></td></tr><tr><td valign=top> 

Comment 7

[leger]

Putting on the PDT+ radar for beta1.

Comment 8

[rickg]

Troy -- please hang on to this bug; performance in m14 is really sucking on all 
platforms (looks 4X slower). If possible, I'd like to know where.

Comment 9

[troy]

No, I do not want this PDT+ bug. If things are slower, then it's not becaue of 
layout. We have added reflow command coalescing and several other changes to 
improve performance and that's it

We haven't added any new features or any new code for that matter. Maybe it's 
because of XBL or the network code or I don't know what, but if things are 
slower in M14 it's not core layout...

Comment 10

[Paul Wyskoczka]

Here's some more information.  I loaded www.excite.com using the 1/25/00 windows build  and it took about 6-7 seconds.  I then tried 
it using the 2/14/00 build and it took about 16 seconds.  I ran these page load back to back so there should be no network issue.  I am 
running Windows 95 on a 133mz machine with 48 mb of memory.  Looks like we have regressed like Chirs has mentioned.  I'm going 
to reopen this bug.

Comment 11

[Chris Waterson]

bring it.

Comment 12

[troy]

Fixed by Vidur. The content sink now avoids notifications in the middle of a 
table row

We verified on two very slow machines in the QA lab that this reduced the time 
it takes to load www.excite.com from 26 seconds to 6 second

Comment 13

[leger]

Adding verifyme keyword.

Comment 14

[hamerly]

My testing  as part of verification-a-rama suggests this is not fixed.
300 MHz /128 MB / Win98 machine
page load of www.yahoo.com
4.72  1.32 seconds, sigma = 0.15 secs  [RTM build]
M13   2.12 seconds, sigma = 0.20 secs  [checkpoint release]
M14   8.19 seconds, sigma = 0.31 secs  [2000021516 build]

Comment 15

[troy]

We think there's something specific to laptop machines running Win98. When we 
marked this FIXED yesterday, Vidur and I tested on two Win98 machines in the QA 
lab (one a 90MHZ Pentium and one a 130MHZ Pentium) and with the change we 
saw a very large improvement (over the previous day's build) and layed out 
excite.com as fast as Navigator

On my laptop running Win98 I also see the load of excite.com and yahoo.com to be 
very slow (much slower than Navigator)

Comment 16

[troy]

Further investigation leads me to believe it's a general Win98 problem (and not 
specific to laptop machines). My desktop machine here at home can run Win98 and 
performance is miserable on it as well, and it isn't a laptop

Comment 17

[Paul Wyskoczka]

I also tried www.excite.com on the latest build (2000021715) using Windows95 and the timing seems to remain the same as before 
around 20 secs.  I also don't see any improvement.

Comment 18

[troy]

Okay, I have a fix to gfx that on my machine speeds things up. The regression 
was that were're currently making thousands of extra calls to the GDI 
SelectObject() function to select fonts

I added back the code that checks for the case where the font we're using is the 
current font and then doesn't do a SelectObject() call

Comment 19

[Erik van der Poel]

Added Roger to Cc list.

Comment 20

[troy]

Changes to Windows specific gfx code. Changed nsFontMetricsWin.cpp and 
nsRenderingContextWin.cpp to reduce the number of ::SelectObject() calls when 
measuring text and rendering text.

Now we now longer call ::SelectObject() from the GetWidth() and DrawString() 
functions in nsFontMetricsWin.cpp, and instead we only do the calls from 
nsRenderingContextWin.cpp after first checking whether the font is the same as 
the last font we used

Roger, I did not change the GetBoundingMetrics() functions, because I don't know 
the code very well and I didn't want to break anything

Comment 21

[rbs]

I will have a look, and also sync the changes I made for bug 6585. These
changes should also help performance somewhat because maps are moved from
PRUint8* to PRUint32* (in parity with what is done in gfx/gtk). With these
changes, sizes of map-related loops are reduced by a factor of 4, and the
bitwise operations involved on maps should in principle blend better on 
the Windows' 32-bit architecture.

Comment 22

[Christian Mattar]

Yep, definitely much faster.