Summary: For pages in the several hundred KB and up size range, display performance and the UE during loading is *seven to twelve* times worse with Mozilla than NN 4.7 for file:///... and http://127.0.0.1/... pages. This is much worse than the disparity for pages loaded over a slow link. Worse, for these pages, the local load time was hardly any better than the load time through a 28.8 modem. And the CPU was maxed out - for a < 3KB/s data rate. The impact of the slow, grinding, loading of long pages on the User Experience gets significantly worse as the long page contiues to load, until it is complete. [Stop], [Back], scrolling, etc, that may be delayed by a substantial fraction of a second on a slower machine when 50K of a page is loaded may be delayed by two or three seconds when 500K of the page is loaded. Worse, events queue up if the first event is not handled immediately. This may be amusing if the user presses [PgDn] several times within a second, but it may be very annoying if the [Back] button is pressed several times within a second. A. The MySQL manual at <URL:http://www.tcx.se/Manual/manual.html> (1.4 MB) This page is a typical long technical document that uses straightforward html markup without relying on tables for layout, images, or specified positioning. Here are some stats, followed by observations: Server Mozilla 1999-11-08-09-M11 NN 4.7 -------------------------------------------------- www.tcx.se 636s 510s (x1.3) 127.0.0.1 510s 42s (x12.1) file:/// 512s 44s (x11.6) 1. Clicking below the slider repeatedly, as soon as the previous click caused scrolling, showed a discernable increase in sluggishness within just a few clicks - but it was much worse two minutes later, and worst of all in the last 20 seconds of loading. 2. During this entire time, the CPU was nearly maxed out, despite the fact that, even locally, the data rate never exceeded 3KB per second. 3. During loading, the least scrolling delay came a few seconds after the data flow from Sweden temporarily slowed to a crawl - even if it sped up again within a second or two. The scrolling delay was worse for the local server and local file access at all times. B. U.S. v. MS "Findings of Fact" <URL:http://usvms.gpo.gov/findfact.html> (.4M) This document is structurally very simple, but, aside from the first 50 lines or so, is entirely contained in single-cell, 600 px wide table. NN 4.x displays nothing beyond the first screenful or two (and obviously scrolling has no effect) until the page is complete. Server Mozilla 1999-11-08-09-M11 NN 4.7 --------------------------------------------------- usvms.gpo.gov 312s 80s (x3.9) 127.0.0.1 333s 45s (x7.4) file:/// 300s 45s (x6.7) 1. Both browsers take proportionately much longer to completely load this page than the MySQL manual from local server or storage, based on size. The TABLE must have something to do with this. 2. Mozilla gets more sluggish, faster, at scrolling with this page than with with the MySQL manual - upt to a 4 second delay! 3. After using a click in the scrollbar or the [PgDn] or [spacebar] key to scroll down a page, another request for the same takes much less time to cause the page to scroll if the user waits 10s or more first. 4. It is quite easy to queue up several events immediately after an event is serviced; all of these events will be serviced in quick succession - except multiple clicks on a toolbar button, which often results in a crash. Tested with: Windows NT on a Pentium 120, 64 MB +96MB Swap, nothing else running, just after a reboot. Network link through router connected to a 28.8 modem link to a router 2 hops off a T1 to a well-connected NSP. Apache 1.3.9 server running as a service. Speculation: B.3. may be a clue - are things happening during layout (reflows) that keep invalidating data needed for knowing how far to move the scrollbar slider? If this is happening for regions waaaay offscreen, it might make sense to not invalidate so accurately.

This may belong on the dependency list at bug 8691 - "Tracking bug for examples of page loading performance problems where we have significant differences betweeen current seamonkey and other browsers."

This is not a UI bug. re assign it to choffman and I think he has better idea who is working on similar performance problems.

-> jevering

Rick, this looks like the same problem with loading large pages. Is this a parser issue?

Ok -- the "finding of fact" example now loads for me in 4 seconds, much better than reported. I suspect that there is still a reflow issue here, so I'm reassigning to Vidur as a placeholder for later.

The tracking bug that I'm using for layout performance related to the content sink is 17325. The performance of the pages listed here have increased significantly since M11, but we still have a ways to go. *** This bug has been marked as a duplicate of 17325 ***

Using the same older test system... Performance viewing the "MySQL Manual" page from local storage, uncached, now takes 100s, a bit over twice as long as NN 4.7 (improved from 12x). Performance viewing the "findings of fact" page from local storage, uncached, is now twice as good as with NN 4.7 (22s as measured by Mozilla). But most of the UE problems with scrolling still exist. Page-by-page scrolling while loading, for both pages, is a very inconsistent experience: there is a slight delay before scrolling for the first few seconds, then scrolling responsiveness is good, and more importantly, consistent, then, for 7-10 seconds before the [Stop] button greys, there is no response whatsoever to any events (scrolling, menu, toolbar, etc) until the page finishes loading, at which point any and all events queued in this period are handled. On this machine, that UI starvation time it is over one third of the load time for the "findings of fact" page. Scaling this to the 4 second load time reported by rickg@netscape.com, this would still be over a second with no response - in my experience, the faster machine a user is used to, the less comforably they suffer this sort of delay. 4.x can be just as bad with some pages, but several seconds of non-responsiveness is just as annoying there. Note that this testing was done on an older-but-still-useable machine on which Mozilla otherwise has a UI responsiveness equivalent to other Apps, entirely useable. There are still plenty of older pentium machines out there... I will prepare a new bug report for this UI starving problem testing the M12 release when it is available so this bug can be verified resolved; the raw performance problems are no longer hideous (this should have been two bugs in the first place). Tested with: 1999-12-15-16-M12 nightly binary on Windows NT 4.0sp3

Agree...incremental reflows work of Bug 17325 should take care of this. Marking Verified/Duplicate.

Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.