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.

Adding beta 1 keyword

Works fine for me with latest build...

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

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

Re-assigning to QA

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>

Putting on the PDT+ radar for beta1.

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.

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

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.

bring it.

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

Adding verifyme keyword.

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]

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)

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

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.

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

Added Roger to Cc list.

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

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.

Yep, definitely much faster.