Closed
Bug 195408
Opened 22 years ago
Closed 19 years ago
Investigating slow DHTML performance (on 3D testcase)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: markushuebner, Unassigned)
References
()
Details
(Keywords: perf, testcase)
Attachments
(1 file)
120.55 KB,
application/x-gzip
|
Details |
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.
*** This bug has been marked as a duplicate of 117316 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Summary: Investigating slow DHTML performance → Investigating slow DHTML performance
Reporter | ||
Comment 2•22 years ago
|
||
Hold on - this isn't about memory or any footpring problems! pure dhtml performance is being analysed
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Reporter | ||
Comment 3•22 years ago
|
||
Though fixing this might have a positive effect on performance :)
Status: REOPENED → NEW
That url is being investigated in bug 117316 and it has the "perf" keyword.
Reporter | ||
Comment 5•22 years ago
|
||
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.
OS: Windows XP → All
Hardware: PC → All
Updated•21 years ago
|
Severity: normal → major
Priority: -- → P2
Updated•21 years ago
|
Target Milestone: --- → Future
Reporter | ||
Comment 6•21 years ago
|
||
dbradley, could you please provide a profile here.
Comment 7•21 years ago
|
||
I'm currently focussed on some 1.4b issues. Probably won't have time for about another week.
Reporter | ||
Updated•21 years ago
|
Blocks: 21762
Summary: Investigating slow DHTML performance → Investigating slow DHTML performance (on 3D testcase)
Reporter | ||
Comment 8•21 years ago
|
||
Can you try again ...
Comment 9•21 years ago
|
||
Comment 10•21 years ago
|
||
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
Reporter | ||
Comment 11•21 years ago
|
||
Testing build with patch makes this to looking to me noticable faster/smoother.
Depends on: 213813
Comment 12•21 years ago
|
||
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.
Reporter | ||
Comment 13•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
How about profiling the 100% CPU use case? /be
Comment 17•21 years ago
|
||
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•21 years ago
|
||
On request of markus I opened a new Bug 229391.
Comment 19•19 years ago
|
||
Compared to Mozilla1.7, the performance has improved a lot in current trunk builds.
Comment 20•19 years ago
|
||
I don't see any difference in performance using latest 1.8 branch build and IE 6
Reporter | ||
Comment 21•19 years ago
|
||
Okay, marking WFM. Still interested to see if bug 213813 can still bring some more boost.
Status: NEW → RESOLVED
Closed: 22 years ago → 19 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•