Closed Bug 195408 Opened 21 years ago Closed 19 years ago

Investigating slow DHTML performance (on 3D testcase)


(Core :: Layout, defect)

Not set





(Reporter: markushuebner, Unassigned)




(Keywords: perf, testcase)


(1 file)
is a complex DHTML example.
Analysing this will (hopefully) show up where we are still having major 
problems - and that will provide feedback on where to focus on future 
performance work.

*** This bug has been marked as a duplicate of 117316 ***
Closed: 21 years ago
Resolution: --- → DUPLICATE
Summary: Investigating slow DHTML performance → Investigating slow DHTML performance
Hold on - this isn't about memory or any footpring problems!
pure dhtml performance is being analysed
Resolution: DUPLICATE → ---
Though fixing this might have a positive effect on performance :)
That url is being investigated in bug 117316 and it has the "perf" keyword.
The URL is a testcase that also illustrates the problem in bug 117316 [watch 
the reporter :]
What we do in this bug is focusing solely on the DHTML performance aspects of 
Mozilla - investigating this testcase in that view to find out where to focus 
OS: Windows XP → All
Hardware: PC → All
Severity: normal → major
Priority: -- → P2
Target Milestone: --- → Future
dbradley, could you please provide a profile here.
Keywords: testcase
Priority: P2 → --
Target Milestone: Future → ---
I'm currently focussed on some 1.4b issues. Probably won't have time for about
another week.
Blocks: 21762
Summary: Investigating slow DHTML performance → Investigating slow DHTML performance (on 3D testcase)
Can you try again ...
I've attached a patch in bug 213813 that might help with some of these DHTML
issues. I don't expect tremendous gains, but it might be a small step in
improving performance. I'm going to try and get some numbers, but I wanted to
get this out to others that might have more time than I have current. The patch
is at
Testing build with patch makes this to looking to me noticable faster/smoother.
Depends on: 213813
I'm not quite sure if this is the right place for this, but this 3d app (and the
menus at seem to be very slow performers in Mozilla 1.5.
The menus on are as slow in 1.5 as they where in Mozilla 1.0.
In Mozillas 1.1 through 1.4 they are smoking fast.

So I just wanted to let you know that 1.5 has seen a very noticable decrease in
DHTML performace.
Is this related to bug 115247 ?
Kevin, we are trying to speed up layout/dom - unfortunately a lot didn't make 
it up to 1.6 - so really let's hope 1.7a gets better in that respect.
I have a similar 3D example that runs much slower on Mozilla 1.6b than on IE 6
(AMD 900MH, Win2000). The speed is mainly dependent on the number of div
elements (in this case each div is a pixel and there are 368 ot them), e.g the
drawLine function.
Simon's testcase runs much much slower than the current testcase we have in this
bug. In IE, the CPU consumption is around 40% while it is almost 100% in the
latest Mozilla build (winXP, athlon XP1700+, 768MB Ram).
How about profiling the 100% CPU use case?

On Simon's testcase, the top items in the profile are:

  samples %
  1561304 36.0513
   532388 12.2931
   274515  6.3387
   240347  5.5497 oprofiled
   239469  5.5295
   229212  5.2926

Splitting gklayout:

vma      samples  %           symbol name
000a9f38 72181     4.6231     PresShell::AlreadyInQueue(nsHTMLReflowCommand*, ns
001b7038 36047     2.3088     nsRuleNode::CheckSpecifiedProperties(nsStyleStruct
ID, nsCSSStruct const&)
001b0e2e 35075     2.2465     nsRuleNode::WalkRuleTree(nsStyleStructID, nsStyleC
ontext*, nsRuleData*, nsCSSStruct*)
001b6558 31561     2.0215     nsRuleNode::GetStyleData(nsStyleStructID, nsStyleC
ontext*, int)
002746f4 28756     1.8418     nsCSSCompressedDataBlock::MapRuleInfoInto(nsRuleDa
ta*) const
002751c4 23142     1.4822     nsCSSExpandedDataBlock::Compress(nsCSSCompressedDa
taBlock**, nsCSSCompressedDataBlock**)
002fe9de 22114     1.4164     nsViewManager::UpdateWidgetArea(nsView*, nsRect co
nst&, nsView*)
00274f44 21785     1.3953     nsCSSExpandedDataBlock::DoExpand(nsCSSCompressedDa
taBlock*, int)
0029d6c2 21513     1.3779     SelectorMatches(RuleProcessorData&, nsCSSSelector*
, int, nsIAtom*, signed char)
00082c0c 21320     1.3655     FrameManager::ReResolveStyleContext(nsIPresContext
*, nsIFrame*, nsIContent*, int, nsIAtom*, nsStyleChangeList&, nsChangeHint, nsCh
001c2784 19861     1.2721     nsStyleContext::GetStyleData(nsStyleStructID)
001c2c4a 19507     1.2494     nsStyleContext::CalcStyleDifference(nsStyleContext
001a240c 17211     1.1023     nsGenericElement::QueryInterface(nsID const&, void

Splitting mozjs:

vma      samples  %           symbol name
0002fe01 79270    14.8895     js_Interpret
0003fc19 34484     6.4772     js_LookupProperty
0001110c 22846     4.2912     JS_GetClass
00020d74 22417     4.2107     js_dtoa
0002f06e 20291     3.8113     js_Invoke
0004035e 20254     3.8044     js_GetProperty
000534d9 18534     3.4813     js_SearchScope
00020b4c 17705     3.3256     quorem
0001f201 17173     3.2257     multadd
00011273 16688     3.1346     JS_GetPrivate
0004072b 14541     2.7313     js_SetProperty
0001ec96 14431     2.7106     SearchTable
0000d000 13361     2.5096     anonymous symbol from section .plt
0001eea1 13101     2.4608     JS_DHashTableOperate
000114a2 11239     2.1111     JS_GetParent
On request of markus I opened a new Bug 229391.
Depends on: 240934
Compared to Mozilla1.7, the performance has improved a lot in current trunk builds.
I don't see any difference in performance using latest 1.8 branch build and IE 6
Okay, marking WFM.
Still interested to see if bug 213813 can still bring some more boost.
Closed: 21 years ago19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.