it took about 2 minutes to render on a Duron 1.4/256 MB. During that time firebird was completely unresponsive. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031128 Firebird/0.7+
Dupe of bug 13350?
Get some stack samples. It doesn't sound like the existing DOMBranchCallback triggers are firing. /be
Created attachment 136583 [details] two stack traces Attached is a file with two stack traces. I guess the latter of two is more relevant than the former. I took two more stack traces, but they don't look relevant. On my P III 800MHz w/384MB, it took Mozilla-Xft about 20 minutes to render the page. It took Mozilla-Xft ~10 minutes to render the 'pre-compiled' (i.e. no JS but HTML only ) version (available at http://www.macchiato.com/unicode/UnicodeChart.zip). I downloaded the zip file, uncompressed it and load it up locally. Needless to say, Mozilla is a lot more responsive while rendering the precompiled html than while rendering the JS version. FYI, MS IE also asks whether or not to abort.
I was wrong about the perf. difference between JS and 'precompiled' version. It took about the same time to render both (about 10minutes). And, the result of profiling indicates that it's not JS but Gtk(Xft) in which Mozilla spent the longest time. Html version profile result: Total hit count: 4598 Count %Total Function Name 550 12.0 _XftFontUncacheGlyph 161 3.5 nsCachedStyleData::GetStyleData(nsStyleStructID const&) 129 2.8 nsVoidArray::Count() const 76 1.7 nsVoidArray::SafeElementAt(int) const 74 1.6 nsCellMap::GetDataAt(nsTableCellMap&, int, int, int) 63 1.4 nsCellMap::GetCellInfoAt(nsTableCellMap&, int, int, int*, int*) 51 1.1 nsVoidArray::ElementAt(int) const 50 1.1 TT_Load_Simple_Glyph 45 1.0 nsRuleNode::GetParentData(nsStyleStructID) 44 1.0 nsIFrame::GetStyleData(nsStyleStructID) const JS version profiling result: Total hit count: 6532 Count %Total Function Name 523 8.0 _XftFontUncacheGlyph 107 1.6 nsHTMLReflowCommand::GetTarget(nsIFrame*&) const 76 1.2 PR_GetCurrentThread 63 1.0 nsCachedStyleData::GetStyleData(nsStyleStructID const&) 61 0.9 nsVoidArray::Count() const 56 0.9 nsTraceRefcntImpl::LogAddRef(void*, unsigned, char const*, unsigned) 53 0.8 __pthread_getspecific 50 0.8 nsVoidArray::ElementAt(int) const 49 0.8 memset 47 0.7 nsAutoRefCnt::operator unsigned() const 45 0.7 nsTraceRefcnt::LogAddRef(void*, unsigned, char const*, unsigned) 42 0.6 TT_Load_Simple_Glyph 42 0.6 nsTraceRefcnt::LogRelease(void*, unsigned, char const*) 38 0.6 nsQueryInterface::operator()(nsID const&, void**) const 37 0.6 nsID::Equals(nsID const&) const 35 0.5 CellData::IsDead() const 34 0.5 nsTraceRefcnt::LogAddCOMPtr(void*, nsISupports*) 33 0.5 SearchTable 31 0.5 gray_render_line 31 0.5 nsCellMap::GetDataAt(nsTableCellMap&, int, int, int) 29 0.4 nsTraceRefcntImpl::LogAddCOMPtr(void*, nsISupports*) 27 0.4 nsTraceRefcntImpl::LogReleaseCOMPtr(void*, nsISupports*) 25 0.4 _int_malloc 23 0.4 __libc_malloc 23 0.4 PL_DHashTableOperate 22 0.3 nsCOMPtr::get() const 22 0.3 nsStyleContext::GetStyleData(nsStyleStructID) 22 0.3 nsIFrame::GetNextSibling() const 22 0.3 nsVoidArray::SafeElementAt(int) const 21 0.3 nsRuleNode::GetStyleData(nsStyleStructID, nsStyleContext*, int) 21 0.3 nsTraceRefcnt::LogReleaseCOMPtr(void*, nsISupports*) 21 0.3 gray_quick_sort 20 0.3 JS_GetPrivate 20 0.3 gray_render_scanline 20 0.3 nsTraceRefcntImpl::LogRelease(void*, unsigned, char const*) 19 0.3 PresShell::AlreadyInQueue(nsHTMLReflowCommand*, nsVoidArray&) 18 0.3 _PR_x86_AtomicIncrement 18 0.3 FT_Stream_GetChar 16 0.2 CNavDTD::WillHandleStartTag(CToken*, nsHTMLTag, nsIParserNode&) 15 0.2 nsID::Equals(nsID const&) const 15 0.2 nsTableCellMap::GetColCount() const 15 0.2 free 15 0.2 FT_MulFix 15 0.2 gray_render_conic 15 0.2 nsLineLayout::ReflowFrame(nsIFrame*, unsigned&, nsHTMLReflowMetrics*, in 15 0.2 SelectorMatches(RuleProcessorData&, nsCSSSelector*, int, nsIAtom*, signe 15 0.2 nsCOMPtr_helper::nsCOMPtr_helper() 15 0.2 nsRuleNode::GetParentData(nsStyleStructID) 14 0.2 times 14 0.2 do_QueryInterface(nsISupports*, unsigned*) 14 0.2 nsTableRowFrame::ReflowChildren(nsIPresContext*, nsHTMLReflowMetrics&, n 13 0.2 nsPresContext::GetBidiEnabled(int*) const 13 0.2 memmove 13 0.2 js_Interpret 13 0.2 PR_AtomicIncrement 13 0.2 nsAutoRefCnt::operator unsigned() const 12 0.2 Stopwatch::Stop() 12 0.2 js_Invoke 12 0.2 nsCellMap::AppendCell(nsTableCellMap&, nsTableCellFrame*, int, int, nsRe 12 0.2 nsTraceRefcnt::LogCtor(void*, char const*, unsigned) 12 0.2 nsDocument::QueryInterface(nsID const&, void**) 12 0.2 PR_SetThreadPrivate 12 0.2 Stopwatch::Start(int) 12 0.2 nsTraceRefcntImpl::LogCtor(void*, char const*, unsigned) 12 0.2 nsHTMLReflowState::InitConstraints(nsIPresContext*, int, int, nsMargin*, 11 0.2 JS_GetClass 11 0.2 gray_hline 11 0.2 StyleSetImpl::StopTimer(unsigned) 11 0.2 nsBCTableCellFrame::GetType() const 11 0.2 nsTableCellFrame::Reflow(nsIPresContext*, nsHTMLReflowMetrics&, nsHTMLRe 11 0.2 nsCSSFrameConstructor::ContentAppended(nsIPresContext*, nsIContent*, int 11 0.2 _PR_x86_AtomicDecrement 11 0.2 Stopwatch::Start(int) 11 0.2 Stopwatch::Stop()
Testing the JS version on a non-xft, non-freetype build, the top of the flat profile is: Total hit count: 26227 Count %Total Function Name 6246 23.8 nsFontMetricsGTK::GetTextDimensions(unsigned short const*, unsigned, nsTextDimensions&, int*, nsRenderingContextGTK*) 5167 19.7 nsFontMetricsGTK::LocateFont(unsigned, int&) 3485 13.3 nsFontMetricsGTK::SearchNode(nsFontNode*, unsigned) 732 2.8 nsFontMetricsGTK::PickASizeAndLoad(nsFontStretch*, nsFontCharSetInfo*, unsigned, char const*) 420 1.6 nsFontMetricsGTK::FindAnyFont(unsigned) So the problem seems to be, again, the various linear walks we do along the font array in that code.... Of those 26000 hits, 17354 are under nsTextFrame::MeasureText, almost all of it under the various forms of GetTextDimensions.
bz, can you try my patch in bug 129387? After applying the patch, you have to regenerate ut/uf files in intl/uconv/ucv(ja|tw|cn|ko) directories by running the script attached there. It should speed up |GetTextDimension| by replacing the linear search with a binary search in Unicode -> font encoding.
Can do, if you post clear step-by-step instructions in that bug as to what to run where and in what order....
I'll give the step-by-step instruction later in that bug. In the meantime, I tested the JS version on Windows XP (1.6GHz, 512MB RAM). It took Mozilla ~40sec while it took MS IE ~20 sec. MS IE prompted me to abort it twice saying that the script could make IE unresponsive, (but I declined). Clearly, the bottleneck on Linux is Gtk, but on Windows, the JS engine might be a factor in the 2-fold difference. After installing Linux on this machine, I'll see how well Mozilla does on it.
Please, let's not try to guess where the problem lies; only profiles can tell us for real. Performance problems are rarely where one expects. :-)
My personal bet on the 2x perf difference is layout, not JS engine... Again, a total stab-in-the-sky. Someone needs to profile this on Windows.
This bug has been buried in the graveyard and has not been updated in over 5 years. It is probably safe to assume that it will never be fixed, so resolving as WONTFIX. [Mass-change filter: graveyard-wontfix-2014-09-24]