User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 When trying to load the sample URL in firefox, the CPU usage goes up to 100% and firefox no longer responds. Reproducible: Always Steps to Reproduce: 1. open the sample url 2. watch ;) Actual Results: Firefox hangs Expected Results: Display the XML data

doesn't hang for me (Mozilla, 1 day old CVS trunk)

i'm using the latest firefox release (1.0.2) available on mozilla.org

Ok, after waiting (about half a minute) it got responsible again, looks like that's the time it needs to process rendering the document, but given it's a P4 machine with 2.8Ghz/HT and 1GB of physical memory, that's pretty slow. I tried loading the document in IE and it displays it instantly without any problems

Can you please try a FF nightly truk build ? The FF1.X branch is really old (April 2004..)

*** Bug 289151 has been marked as a duplicate of this bug. ***

it's not fixed in this nightly build for win32: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-04-05-06-aviary1.0.1/

I get this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+ Confirming bug.

I get this with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050405 Firefox/1.0+ Would need help to spot wich part of firefox is doing this.

I get this in current trunk Linux builds too. Profiler sez (for a run from start of freeze for about 30 seconds; I killed the app after that): Total hit count: 215769 215769 txMozillaXSLTProcessor::TransformToFragment Under TransformToFragment almost all the time is spent under txXSLTProcessor::execute (213745 hits), and breaks down as follows: 62499 txStartLREElement::execute(txExecutionState&) 58447 txLREAttribute::execute(txExecutionState&) 42308 txEndElement::execute(txExecutionState&) 16370 txValueOf::execute(txExecutionState&) 13828 txText::execute(txExecutionState&) 13765 txApplyTemplates::execute(txExecutionState&) 1573 txPushNewContext::execute(txExecutionState&) and some small fry. Digging down further, we're ending up with 34627 hits under nsDocument::CreateElementNS, 38320 hits under nsGenericElement::SetAttributeNS, etc.... The XML file is about 1.6 megs. I'll attach a zipped up version of it and the jprof output.

Sounds like this is 'just' another xslt perf bug. Though it's awesome to have a profile! The patch in bug 208172 is known to have huge effect on the prettyprint stylesheet, so we really need to get some tracktion there again. Other interesting things that are probably not so relevant to the prettyprint (given hos much optimized xpath help there) is: * We spend 8% in SetAttributeNS discounting time in SetAttr. I.e. that is time converting namespaceuri and localname strings to nsid and localname atom * We spend 7% in the same conversion when creating elements * We spend 25% in txMozillaXMLOutput::closePrevious. About half of that creating textnodes and the rest inserting nodes in the tree. * We spend 2% in atom->string conversion and another 2% pushing that string in txStartLREElement. Then another 2% popping that string in txEndElement. * We waste 4.5% in AttributeValueTemplate::evaluate where we could have just used a txLiteralExpr directly. Note that all these percentages are non-overlapping.

More profile ogling: We spend about 1.5% in nsSubstring::Replace called from txMozillaXMLOutput::characters. Most of this is allocating the new buffer, very little is the actual memcopy. If we had a way of truncating the string without freeing any possibly allocated memory we'd save oursafe both this alloc as well as the free in closePrevious (though the free seems to be few cycles). Alternativly we could instead of first storing a local string and then creating a textnode in closePrevious, create the textnode right away and just append the data there as we go. Though this would probably be slower since we'd end up reallocating more memory on each append. Almost 40% of nsGenericElement::InsertChildAt is spent in nsRange::OwnerChildInserted. It shouldn't be neccesary to spend that much time in range code so here might be room for general Tp improvement. We spend a total of 7% in QI. 4% is from txMozillaXMLOutput and almost 2% is range code. Only some 6.5% is spent in findTemplate which is very surprising seing that that is what optimized xpath should speed up for the prettyprint stylesheet. Could be just how the profile was sliced, or that this xml file is structured differently then the one I tried. Actually, looking at the xml i'm guessing it's a combination, we should get a big findTemplate hit at the beginning (building a list of the <Cube time="..."> elements) but after that just smaller ones. Interesting notes about opening this in IE: IE doesn't show the entire file instantly but rather takes quite a while to stream it into the browser. Though the total time is most likly significantly shorter then our. The streaming is quite beautiful and the browser UI is attentive during the entiere streaming. Including pressing stop or scrolling around. This is probably helped by the fact that they (we think) create the XSLT result as a textfile which is then parsed through the normal html parser. Collapsing and uncollapsing elements is significantly faster at the top of the file rather then at the bottom. I suspect this is because IE only reflow down to where the user is viewing. Though they do seem to get at least an approximate total length anyway. Quite a neat trick in any event. Loading the file locally gives a warning that the page contains active content. Open and collapse won't work unless you tell it that you want active content enabled for the page :)

Still getting this with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a9pre) Gecko/2007100804 Minefield/3.0a9pre ID:2007100804

A lot has changed since the profile was made so if we want to do further work we should create a new profile. Lets just do that in bug 197956

For what it's worth, I did a quick profile of this XML file and it looks just like the other profiles: we build a huge DOM and then render it all at once. Any non-incremental solution will have a "hang" like this.