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

VERIFIED FIXED

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
18 years ago
9 years ago

People

(Reporter: chriss, Assigned: Chris Waterson)

Tracking

Trunk
x86
Windows 98
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], URL)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
Adding beta 1 keyword
Keywords: beta1

Comment 2

18 years ago
Works fine for me with latest build...
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Keywords: beta1
Resolution: --- → WORKSFORME
(Reporter)

Comment 3

18 years ago
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
(Reporter)

Comment 4

18 years ago
Reopening the bug. Would like more data from QA to validate what I'm seeing
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 5

18 years ago
Re-assigning to QA
Assignee: troy → petersen
Status: REOPENED → NEW
(Reporter)

Updated

18 years ago
Summary: Page load time takes twice as long as M13 on my netscape → Page load time takes twice as long as M13 on yahoo.com, my netscape
(Reporter)

Comment 6

18 years ago
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

18 years ago
Putting on the PDT+ radar for beta1.
Assignee: petersen → rickg
Keywords: beta1
Whiteboard: [PDT+]

Comment 8

18 years ago
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.
Assignee: rickg → troy

Comment 9

18 years ago
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...
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → INVALID

Comment 10

18 years ago
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 11

18 years ago
bring it.
Assignee: troy → waterson
Status: REOPENED → NEW

Comment 12

18 years ago
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
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 13

18 years ago
Adding verifyme keyword.
Keywords: verifyme

Comment 14

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
Added Roger to Cc list.

Comment 20

18 years ago
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

18 years ago
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

18 years ago
Yep, definitely much faster.
Status: RESOLVED → VERIFIED

Updated

9 years ago
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.