From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 BuildID: 2001122106 Mozilla takes an enourmous amount of cpu-time while parsing the big <select> tag on the page. On a Celeron 466 the page with the select tag with 6860 option tags inside the select tag takes about 50 seconds to display. 50 seconds of 100% cpu-time that is, not just to load the site. Reproducible: Always Steps to Reproduce: 1. Just look at the site. Actual Results: The problem occured Expected Results: The output is correct, the performance is just bad.

changing compponent

rjesup? Maybe we could be adding elements to the mElements nsISupportsArray in nsHTMLOptionCollection (select.options[]), but I have heard that nsISupportsArray has a nice exponential algorithm for expanding its memory rather than just extending itself one at a time. It is an open question whether this is necessarily a problem ... the times you are seeing is at least an order of magnitude faster than what was there even 3-4 months ago. On your computer, even, this is processing over a hundred options a second, and on mine, 300-350. 3ms per option, from start-of-parse to creation of content node with *all* DOM capabilities intact. It is possible that 3ms is just the price we pay. (Though if we can find something to make it better, great!)

I'll jprof it. nsSupportsArray has (now) a nice exponential expansion (I added that last fall). Must be an O(n^2) thing somewhere, perhaps in frame construction? (we know there are some of those).

someday (hopefully soon) we will be switching over to XBL form controls

Jprof to be posted. Comments (all times are % of total hits). Dual-450 Linux, jp_period=0.0015, not realtime. Biggest direct hit is nsFrameList::LastChild() called indirectly from nsCSSFrameConstructor::ContentAppended(), at about 8% Biggest total is ReflowLine(), for 66%. Inside Reflow, we spend ~10% in nsHTMLReflowState::nsHTMLReflowState, mostly doing InitConstraints(). 8% in nsBlockFrame::PlaceLine() 6% in nsFontCache::GetMetricsFor() 3% in nsFont::Equals() (mostly case-insensitive compares) 13% in nsTextFrame::Reflow() 7% in nsTextFrame::MeasureText() 3% in nsTextTransformer::GetNextWord() 18% in nsHTMLSelectElement::InsertOptionsIntoList() 17% in nsGenericHTMLElement::UnsetAttr() 18% in nsCSSFrameConstructor::ContentAppended() 9% in nsCSSFrameConstructor::ConstructFrame() 8% in nsCSSFrameConstructor::ContentAppended() (see above)

Are we reflowing too many times or is a single reflow taking too long?

-->

I'm pretty certain we're reflowing on every option add, or close to. The select box changes width multiple times during the load.

I'm going to write this one off as "will be fixed when XBL select lands," since XBL select is actually rather close to being turned on.

Moving to Mozilla1.1

With build 2002061408 down from 50 seconds in the original report to 11 seconds now. Much better, but still more than twice as slow as IE5.5

This could be even better once bug 113491 is fixed. I don't see us getting any better after that.

http://qa.mandrakesoft.com/show_bug.cgi?id=5012 has about 8400 option items in its 1st select list. It is noticably slow to load on my hardware, 2 K6/2-550's and a K6/2-500. Using 1.5b on Linux & W98, and 1.4 on OS/2, CPU pegs for an appreciable time, about 20 seconds to load the page on OS/2. Even worse is view source on this page, 100 seconds on OS/2, 54 seconds on Linux, and 60 seconds on W98. Performance is similarly poor at http://qa.mandrakesoft.com/query.cgi. Attempting to use one of these two Mandrake pages in 1.5b for OS/2 resulted in the system locking up, requiring cold reboot.

retargeting

I get the same problem using: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040927 Firefox/0.10 I'm running a Athlon MP 2100+, and it takes me twice as long to load up a page with 9000+ <option> within a <select>, as well navigate and select the element.

<2 sec to load WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091122 Minefield/3.7a1pre