an extreme test case for JS engine and Gfx: Unicode 4.0 code chart in Javascript



Core Graveyard
14 years ago
3 years ago


(Reporter: Jungshik Shin, Unassigned)


({intl, perf})

intl, perf

Firefox Tracking Flags

(Not tracked)




(1 attachment)



14 years ago
The page at the URL lists all the Unicode characters (in 4.0) with Javascript. The 
author of the page wrote that it took MS IE on his notebook (I don't know the 
spec of his notebook) 30 seconds to render the page. According to him 
Opera(on Windows) took much longer but rendered the page gradually. I'm 
testing it on Linux (P III, 800MHz, 384MB RAM) with Xft build and am still 
waiting after a few minutes.  
Konqueror on the same system also rendered the page gradually (it also  
prompted me to abort ot to continue every minute saying that the script is 
gonna freeze Khtml engine). After 10 minutes or so, I gave up. At that point, it 
covered about 30% of the BMP.  
I'm gonna test Opera 7.2 on the same system after I'm done with Mozilla 


14 years ago

Comment 1

14 years ago
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
Dupe of bug 13350?
Get some stack samples.  It doesn't sound like the existing DOMBranchCallback
triggers are firing.


Comment 4

14 years ago
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

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 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

FYI, MS IE also asks whether or not to abort.

Comment 5

14 years ago
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*,
 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,
 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&,
 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.

Comment 7

14 years ago
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....

Comment 9

14 years ago
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.
Product: Core → Core Graveyard
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]
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.