98627 - [DHTML PERF] Extremely slow page load

Status: RESOLVED DUPLICATE of bug 21762

(Core :: Layout, defect)

Description

[shelby]

Causes a several seconds delay before following web page renders, due to an 
apparently very slow Javascript performance while the dhtml menus are built on 
the following page:

http://downloadfast.com/bugzilla.php

IE does not have this delay.

It is possible that the delay in the DOM or Layout, but I suspect first 
Javascript.

Also probably DOM related, the dhtml drop menus are noticeably and annoying 
severely more sluggish than in IE5.5.  And notice that sometimes the DIV first 
appears on the left before moving to it's correct location.  Perhaps this 
rendering sluggishness (not the main delay above) could be complicated by the 
500msec timing delay used in the javascript code, but I doubt it as it works 
fine in IE.  In any case, there is some bug as the timing code is correct.

I reported other bugs today on same page, but doubt they are related: Bug#98617 
and Bug#98621

Comment 1

[Phil Schwartau]

Confirming bug with trunk binary 20010828xx WinNT. My CPU stays pinned
at 100% for around 20 seconds. With NN4.7 the page loads considerably
faster than that. OS : Other --> All.

I don't think it's JS Engine; every time I interrupt the load, I get
a stack trace involving Layout functionality. Will attach a sample below - 

Comment 2

[Phil Schwartau]

Attachment: WinNT stack trace after manual interrupt when CPU=100%

Comment 3

[Phil Schwartau]

Based on stack trace, reassigning to Layout component for further triage -

Comment 4

[shelby]

1. It is not fair to compare to NN4.7, because using entirely different 
algorithm and <select> in that case.

2. However, it does appear that the slowness is after all data has been 
downloaded over the network, so it does appear to be an algorithmic problem.

3. If necessary to trace the problem, I can provide an prettier commented 
version of dhtml_menu.js.  However, I will only provide via email directly to 
one person, as this is code we want to protect from public viewing.

4. If you study this dhtml_menu.js code and the the configuration files 
category_menu.js and platform_menu.js, you will notice this is probably the 
most elegant and compact dhtml menus ever created.  Thus I plan to incorporate 
it as a drag+drop element in our extremely Cool Page web page creation tool 
(coolpage.com) in coming month or so.  I raise this point, because you should 
be aware that Cool Page has several hundred thousand users, and we have a link 
from our web site to 15,000+ web sites made with Cool Page.  You definitely 
want to fix this bug asap, unless you want Netscape 6.x choking over thousands 
of web pages.

Shelby Moore
programmer or co-programmer of Cool Page, Art-o-matic, Corel Painter, WordUp, 
EOS PhotoModeler etc.
CEO 3Dize, Inc. (coolpage.com) and DownloadFAST.com, Inc.

Comment 5

[Phil Schwartau]

cc'ing jrgm - 

Comment 6

[shelby]

I am open to making changes in our dhtml_menu.js file, if you discover any code 
which is not ideal or correct, if they will help solve the problem for current 
Mozilla releases.

Comment 7

[Markus Hübner]

updating

Comment 8

[Marc Attinasi]

We need a profile of this page...

Comment 9

[John Morrison]

Attachment: jprof profile (using JP_DEFER and JP_PERIOD=0.0015)

jprof profile (using JP_DEFER and JP_PERIOD=0.0015); used a test page 
http://jrgm/bugs/98627/page2.html which is stripped down to just the building 
of the dhtml menu. Takes ~25 seconds to load, linux/500MHz/128MB, current trunk
mozilla build.

Top 20 sampled active functions (from the 'flat profile'):

Total hit count: 1323
Count %Total  Function Name
58   4.4     nsStyleContext::GetStyleData(nsStyleStructID)
54   4.1     nsRuleNode::GetStyleData(nsStyleStructID, nsIStyleContext *, int)
39   2.9     nsHTMLReflowState::InitConstraints(nsIPresContext *, int, int)
33   2.5     nsCOMPtr_base::~nsCOMPtr_base(void)
33   2.5     nsLineLayout::ReflowFrame(nsIFrame *, nsIFrame **, unsigned int &,
nsHTMLReflowMetrics *, int &)
33   2.5     nsTextFrame::Reflow(nsIPresContext *, nsHTMLReflowMetrics &,
nsHTMLReflowState &, unsigned int &)
25   1.9     nsCOMPtr_base::begin_assignment(void)
22   1.7     nsCaseConversionImp2::CaseInsensitiveCompare(unsigned short *,
unsigned short *, unsigned int, int *)
22   1.7     nsInlineFrame::IsEmpty(int, int, int *)
20   1.5     nsBlockFrame::ReflowDirtyLines(nsBlockReflowState &)
19   1.4     nsBlockFrame::ComputeFinalSize(nsHTMLReflowState &,
nsBlockReflowState &, nsHTMLReflowMetrics &)
17   1.3     nsLineLayout::VerticalAlignFrames(nsLineLayout::PerSpanData *)
17   1.3     nsBlockFrame::ReflowBlockFrame(nsBlockReflowState &,
nsLineList_iterator, int *)
15   1.1     PR_AtomicIncrement
14   1.1     ComputeLineHeight(nsIRenderingContext *, nsIStyleContext *)
13   1.0     nsFontCache::GetMetricsFor(nsFont &, nsIAtom *, nsIFontMetrics *&)

13   1.0     nsBlockFrame::Reflow(nsIPresContext *, nsHTMLReflowMetrics &,
nsHTMLReflowState &, unsigned int &)
12   0.9     nsTextTransformer::GetNextWord(int, int *, int *, int *, int *,
int, int)
11   0.8     nsTextFrame::MeasureText(nsIPresContext *, nsHTMLReflowState &,
nsTextTransformer &, nsILineBreaker *, nsTextFrame::TextStyle &,
nsTextFrame::TextReflowData &)
11   0.8     _PR_x86_AtomicIncrement

Comment 10

[Marc Attinasi]

From the profiles, it looks just liek we are doing too much reflowing, and
possibly whacking on the Style System too hard in the process.  Off to 1.0 for
now...

Comment 11

[Kevin McCluskey (gone)]

Moving to Moz1.1. Engineers are overloaded with other higher priority bugs.

Comment 12

[Fabian Guisset]

Marking as dup of bug 21762, as this bug doesn't demonstrate a specific problem.
Please see my post in npm.dom for more information.

*** This bug has been marked as a duplicate of 21762 ***