Closed Bug 375470 Opened 18 years ago Closed 18 years ago

DOM and/or Javascript slowdown in FF3 as compared to FF2

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.9beta3

People

(Reporter: duncan.loveday, Assigned: mrbkap)

References

Details

(Keywords: perf, regression)

Attachments

(3 files)

test svg file
401 bytes, image/svg+xml
Details
test html file
2.09 KB, text/html
Details
not appending created nodes to dom
1.87 KB, text/html
Details
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.0.3705; .NET CLR 1.1.4322; Media Center PC 4.0) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070316 Minefield/3.0a3pre Executing various DOM manipulations from javascript is noticeably slower on FF3. Reproducible: Always Steps to Reproduce: 1. Open the attached HTML test case in FF2 and then in FF3 2. 3. Actual Results: FF3 is noticeably slower. Expected Results: In an ideal world, FF3 would perform at least as well as FF2, unless there is a good reason such as enhanced functionality that is worth a performance cost. The test case includes manipulations on both the HTML and SVG DOM as well as a tight loop.
Attached image test svg file —
Attached file test html file —
When I ran this a week or two ago the javascript tight loop was about the same but the DOM calls were slower. However, my results just now were Tight 10K SVG 10K SVG 10K HTML loop rectangles text elements DIVs FF2 860 2625 2875 1797 FF3 1156 3188 4077 2437 The SVG part of the test case uses a <g> to avoid the effects of incremental redrawing and layout (see bug 374037).
Keywords: perf, regression
Flags: blocking1.9?
Re-ran this testcase on a different PC this morning and got something closer to my original results, namely javascript tight loop as good or better in FF3 but DOM slower :- Tight 10K SVG 10K SVG 10K HTML loop rectangles text elements DIVs FF2.0.0.3 2234 2703 3344 2172 FF3 1547 3344 4625 2750 FF3 version is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070326 Minefield/3.0a4pre
Could someone look into trying to find a regression date for this one. Could this be another cycle collector regressions?
I've just had a crack at this, only to find that the results the testcase generated are too variable for me to notice a distinct change between Fx2 and the trunk.
A lot of work has gone in lately which should hopefully fix this. Based on comments in bug 375225 I'm marking this non-blocking for now. Would be great if someone could retest and if we're still worse renominate as blocker, and if we're as good or better close as FIXED.
Flags: blocking1.9? → blocking1.9-
I'm happy to retest - is the work you mention landed on the trunk ?
My results for 5 attempts, closing and restarting the browser each time, are Tight 10K SVG 10K SVG 10K HTML loop rectangles text elements DIVs FF2.0.0.3 2235 3047 3453 2438 2250 2859 3452 2437 2250 2812 3327 2156 2156 2781 3452 2344 2234 2906 3016 2422 Average 2225 2881 3340 2359 FF3 1266 3390 4125 2375 1328 3265 3860 2578 1266 3250 3828 2625 1266 3250 4156 2484 1422 3266 3812 2547 Average 1310 3284 3956 2522 FF3 version is Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070503 Minefield/3.0a5pre
One thing to test here is whether the slow down is in DOM or in layout. The testcase appends domnodes to an element which is visible/in-a-document, but what happens if nodes are appended to a domnode which isn't in document (and so no rendering happens).
this tests only DOM, but maybe not perfectly SVG DOM.
Interestingly, this has eliminated the slowdown for the SVG DOM completely even though I though we'd removed the effects of layout by adding elements within a <g>. Tight 10K SVG 10K SVG 10K HTML loop rectangles text elements DIVs FF2.0.0.3 2156 2577 3046 1687 2203 2655 3749 1546 2187 2609 3623 1547 2171 2609 3077 1671 2187 2640 3717 1562 Average 2180 2618 3442 1602 FF3 1453 2327 3343 1702 1438 2483 3233 1875 1453 2405 3374 1687 1405 2640 3405 1984 1438 2514 3280 1953 Average 1437 2474 3327 1840
(In reply to comment #13) > though I though we'd removed the effects of layout by adding elements within a > <g>. Ah, indeed, there is the <g> in the original testcase, my mistake. Though, the new results are interesting. Is svgelement.appendChild slower than it used to be. Regression range for this bug would be great.
When you're testing this in FF2, has layout started yet. I don't recall if we had started layout fully by the time onload fires. If layout hadn't started in FF2 that would explain why FF2 is faster when manipulating DOM that lives in the Document. One way to make sure that layout has started in both builds would be to run the test code off a setTimeout 10ms after onload fires.
Jonas, this bug is an offshoot from bug 374037 which was one I raised after noticing truly massive performance differences with SVG DOM manipulations. It turned out that most of the overhead was indeed to do with layout and reflow but even after eliminating these effects by using a <g> there is still an effect and that was what this bug was specifically about. bug 374037 shows that when setTimeout is used, FF3 outperforms FF2 by some margin.
(In reply to comment #14) > > Ah, indeed, there is the <g> in the original testcase, my mistake. > Though, the new results are interesting. Is svgelement.appendChild slower than > it used to be. Regression range for this bug would be great. > Is your last attachment a valid thing to be testing, adding SVG elements to an arbitrary non-SVG element ? Normally SVG elements would go under an SVG root element under the document. Just wondering if that's effectively a no-op on both versions (e.g. if they ignore it) and hence no performance difference is seen.
Given the cross-document access, please retest once bug 380475 lands?
Blocks: 374037
Depends on: 380475
Duncan, can your retest. This should be renominated if there are still good problems lurking here.
Retested the original test html file just now using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092605 Minefield/3.0a9pre Tight 10K SVG 10K SVG 10K HTML loop rectangles text elements DIVs FF2 906 3063 3484 2219 1485 3078 3437 2125 1492 2423 3434 2097 FF3 1854 2830 2943 2600 1834 2867 3373 2620 1795 2836 3375 2641 Comparing agaist the figures in comment #10 it appears the SVG performance has improved but the HTML performance is about the same, although note that I was using a different PC when I ran the tests for comment #10.
I profiled the "HTML" testcase. Things that jump out at me: 10% unwrapping XOW. Filed bug 397791. 6% nsScriptSecurityManager::CanAccess. We have existing bugs on this. 12% js_LookupPropertyWithFlags. About half of this is nsHTMLDocumentSH::NewResolve. 12% constructing XPCWrappedNatives for all the stuff being created 12% layout object construction under the append to body Basically, this code is almost designed to run as slowly as possible. There's no caching of document.body, nodes are inserted into the DOM one at a time, that sort of thing. That would all have been a problem in 1.8 as well, of course; the only thing that jumps out at me as being different for now is bug 397791.
Depends on: 397791
I do think we should renominate. The 20% same-origin HTML hit this is showing right now is unacceptable.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9- → blocking1.9?
One easy way to test how much of this we can attribute to XOW would be to simply not wrap documents and windows with XOW and rerun the perf tests. We should also try with the XOW removed only from the document since that is something we could potentially do if we fix bug 397791. Mrbkap, could you have a look at this? At least get numbers for non-XOW builds to see if fixing that is enough, or if we need to do other things too.
Assignee: general → mrbkap
Flags: blocking1.9? → blocking1.9+
Simply disabling XOWs isn't really a fair comparison. I'd have to add back the security checks in nsDOMClassInfo. The real fix would be to make security checks not be amazingly slow...
Fixing bug 317240 and reinstating the fast path in bug 289655 would have some. I keep hearing that Tamarin would help more.
Marking this as P2 since this is a perf regression.
Priority: -- → P2
Moving to P1 because of possible regression risks and the fact that this is a perf regression. JST/Jonas you going to have time to help out here?
Priority: P2 → P1
Thanks to some recent work by JST our numbers are very close for div's and tight loop and better for everything else. FF3 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007120504 Minefield/3.0b2pre 730 1423 1638 1228 679 1438 1672 1223 679 1429 1638 1224 FF2 687 1730 1808 1209 616 1724 1797 1183 623 1723 1800 1184
JST has some further optimizations in the pipeline - but they are not ready/safe for Beta2 - so setting the TM to M11 - we'll close this bug out once those land and we cross over for div perf...
Target Milestone: --- → mozilla1.9 M11
Lots of good work going on in the dependency tree for bug 375225. So adding that one to the the dependency tree here too. Jst, you wanna do some profiling on this bug too? Or just test if your patches has improved things here.
Depends on: 375225
Today's trunk vs branch: Tight 10K SVG 10K SVG 10K HTML loop rectangles text elements DIVs FF2 679 1178 1259 840 FF3 570 808 970 765 1.19x 1.46x 1.30x 1.10x So trunk is now faster across the board.
Ok, thanks for testing again, Mike. I'll close this bug out as there's not a whole lot of sense keeping many of these performance bugs open at the same time. The testcase in here is still useful, but this bug is linked into 375225 so the testcase should be findable from there.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: