The above table takes *much* longer to load with mozilla m15 than with IE 4. The machine configurations were as follows. mozilla -->Ultra10, Elite3D, 360MHz, 1GB RAM, Solaris 7. IE -->Dell Precision410 with Windows NT 4.00.1381. Results without decimal points were wall-clock benchmarks, and may be off by a second. Results with a decimal point were reported in the web browser GUI; I rounded these to the nearest tenth of a second.

The test case is available at ftp://ftp.sunmde.com/pub/i2source.html

ooops!. forgot to enter the timings. Mozilla m15 -- 53 secs IE -- 5 secs.

Reassigning to HTMLTables (or networking, perhaps?) reporter: please try with a later nightly build to verify this problem still exists.

I tried it with today nightly build (5/12/00) mozilla on Ultra10, Elite3D, 360MHz,512Mb RAM, Solaris 8 --> 43 seconds!

Windows 2000, 2000051620: Mozilla: 18 seconds IE5: 4 seconds PS - I am marking this as confirmed since it is an issue.

ChrisW, here is a performance bug.

Ok, Something has changed since last week(5/12/00). The times for the above url have increased by 2x. now, on my ultra 10 with the 05/18 nightly binary First Load: 99.17 secs Reload :95.469 secs

Posted raw Quantify 6.0 data at ftp://ftp.mozilla.org/pub/quantify/2000-06-20-39133.qfy.gz Here are some first-order observations. - 3% of the time spent in nsHTMLTags::LookupTag(). It's all spent grovelling through the AVL tree. This should probably be a hashtable. I guess 4.x computed a perfect hash? - CNavDTD::WillHandleStartTag() is using NS_ConvertToString() where it should be using NS_LITERAL_STRING() while notifying the observer service. Altogether, inflating the string and notifying the observer is accounting for 1.77% of the time. Went ahead and changed this: although we'll still have to pay for the observer service, we won't need to inflate. - nsBlockFrame::Reflow() accounts for 30% of the time. Of that: - 5% is spent in nsLineLayout::AddText(). 70% of that time is spent in ::operator new() creating nsTextRun objects. We're down in the noise, but it may make sense to recycle these or something. - 9% is spent nsBlockFrame::SlideLine() placing frame views. This is dominated by nsContainerFrame::PositionChildViews(). It's a recursive function, dominated by the cost of the recursion itself and the cost of addref-ing and release-ing atoms. Atoms are expensive to addref and release because it appears that they're assumed to be threadsafe. Argh! Sheesh, why even use atoms for this? They're tokens! Use enums! Continuing to dig, but wanted to post notes somewheres.

I'm changing the OS to Linux as this bug was tested to occur on Linux platform with M16 distribution. The additional comment here is nothing happens when the URL is typed in. -raghu@eng.sun.com

QA contact update

The testcase is no longer there.

Marking invalid because of missing testcase.

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.