195408 - Investigating slow DHTML performance (on 3D testcase)

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Markus Hübner]

http://www.world-direct.com/mozilla/dhtml/funo/3dcube/index.htm
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.

Comment 1

[R.K.Aa.]

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

Comment 2

[Markus Hübner]

Hold on - this isn't about memory or any footpring problems!
pure dhtml performance is being analysed

Comment 3

[Markus Hübner]

Though fixing this might have a positive effect on performance :)

Comment 4

[R.K.Aa.]

That url is being investigated in bug 117316 and it has the "perf" keyword.

Comment 5

[Markus Hübner]

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

Comment 6

[Markus Hübner]

dbradley, could you please provide a profile here.

Comment 7

[David Bradley]

I'm currently focussed on some 1.4b issues. Probably won't have time for about
another week.

Comment 8

[Markus Hübner]

Can you try again ...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: jprof profile of running this page for a bit

Comment 10

[David Bradley]

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 http://bugzilla.mozilla.org/attachment.cgi?id=128862&action=edit

Comment 11

[Markus Hübner]

Testing build with patch makes this to looking to me noticable faster/smoother.

Comment 12

[Kevin Newman]

I'm not quite sure if this is the right place for this, but this 3d app (and the
menus at www.terminaldesign.com) seem to be very slow performers in Mozilla 1.5.
The menus on terminaldesign.com 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.

Comment 13

[Markus Hübner]

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.

Comment 14

[Simon Speich]

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.
http://www.speich.net/computer/3d.php

Comment 15

[Pascal Chevrel:pascalc]

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

Comment 16

[Brendan Eich [:brendan]]

How about profiling the 100% CPU use case?

/be

Comment 17

[tor]

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

  samples %
  1561304 36.0513 libgklayout.so
   532388 12.2931 libmozjs.so
   274515  6.3387 libc-2.3.2.so
   240347  5.5497 oprofiled
   239469  5.5295 libxpcom.so
   229212  5.2926 libxpconnect.so

Splitting gklayout:

vma      samples  %           symbol name
000a9f38 72181     4.6231     PresShell::AlreadyInQueue(nsHTMLReflowCommand*, ns
VoidArray&)
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
angeHint&)
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

Comment 18

[Simon Speich]

On request of markus I opened a new Bug 229391.

Comment 19

[Martijn Wargers (dead)]

Compared to Mozilla1.7, the performance has improved a lot in current trunk builds.

Comment 20

[José Jeria]

I don't see any difference in performance using latest 1.8 branch build and IE 6

Comment 21

[Markus Hübner]

Okay, marking WFM.
Still interested to see if bug 213813 can still bring some more boost.