Last Comment Bug 227106 - an extreme test case for JS engine and Gfx: Unicode 4.0 code chart in Javascript
: an extreme test case for JS engine and Gfx: Unicode 4.0 code chart in Javascript
Status: RESOLVED WONTFIX
: intl, perf
Product: Core Graveyard
Classification: Graveyard
Component: GFX (show other bugs)
: Trunk
: All All
: -- enhancement (vote)
: ---
Assigned To: general
: Hixie (not reading bugmail)
Mentors:
http://www.macchiato.com/unicode/Unic...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-30 05:00 PST by Jungshik Shin
Modified: 2014-09-24 16:33 PDT (History)
5 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
two stack traces (20.57 KB, text/plain)
2003-12-01 06:00 PST, Jungshik Shin
no flags Details

Description Jungshik Shin 2003-11-30 05:00:43 PST
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 
testing.
Comment 1 Oleg Sidletskiy 2003-11-30 14:12:08 PST
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+
Comment 2 Simon Montagu :smontagu 2003-11-30 14:41:35 PST
Dupe of bug 13350?
Comment 3 Brendan Eich [:brendan] 2003-11-30 14:47:16 PST
Get some stack samples.  It doesn't sound like the existing DOMBranchCallback
triggers are firing.

/be
Comment 4 Jungshik Shin 2003-12-01 06:00:38 PST
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.
Comment 5 Jungshik Shin 2003-12-01 07:27:55 PST
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()
Comment 6 Boris Zbarsky [:bz] 2003-12-01 19:23:15 PST
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 Jungshik Shin 2003-12-01 22:16:11 PST
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.
Comment 8 Boris Zbarsky [:bz] 2003-12-01 22:29:58 PST
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 Jungshik Shin 2003-12-02 00:53:33 PST
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.
Comment 10 Hixie (not reading bugmail) 2003-12-02 03:53:41 PST
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. :-)
Comment 11 Boris Zbarsky [:bz] 2003-12-02 06:49:38 PST
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.
Comment 12 Gordon P. Hemsley [:GPHemsley] 2014-09-24 16:33:14 PDT
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]

Note You need to log in before you can comment on or make changes to this bug.