522748 - Insert Fragment and subsequent DOM Refresh Performance 5x worse than chrome

Status: NEW

(Core :: Layout, defect)

Description

[Clint Priest]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3

I'm not sure if this is the right venue to post this but I wanted to bring this performance to your attention.  I wrote a test case to demonstrate.  This test case is significantly faster than the actual code I'm trying to do this with, however this test shows many more rows than my production code is using.

The issue is with performance of a DOM Refresh, on the test page, the core of what is taking so long is simply:

Range.deleteContents();
Range.insertNode(Fragment);

Doing that with 5000 table rows and 4 columns of data takes 104,812ms.  As a comparison, Chrome handles this operation in 278ms.  

I'm pushing this to the extreme here because I'm writing a reporting tool with pure JS and I'm finding that the JavaScript is not the performance bottleneck, I can re-sort the data in JS in under 200ms but the refresh of the DOM takes 7 seconds, far too long for a user to stay engaged/use it.  This is only on 250 rows of data, I'd like to have many many more rows.

http://www.clintpriest.com/JS_TestCase_DOMSpeed.php

If there's anything else I can provide to help with this, let me know, I prefer to use FF over Chrome and my users would too.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.clintpriest.com/JS_TestCase_DOMSpeed.php
2. Click 'Run Test'

Comment 1

[Clint Priest]

I have also tested this with FF 3.7a1, same results.

Comment 2

[Clint Priest]

I have also tested this with no extensions running.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I just tried this in both Firefox (trunk) and Chrome.  Chrome takes about 230ms over here (4 columns, 5000 rows).  Firefox takes 1100ms.  Definitely much worse, but about 100x faster than comment 0 reports.  Same results in 3.5.3.  Is the "104812ms" number correct?

I'll take a look into the 1100ms number, so confirming base on that.

Comment 4

[Clint Priest]

I just double-checked with FireFox 3.5.3 in Safe Mode, this time 4 x 5000 = 122156ms.  I'll boot windows in Safe mode and post the results that way, maybe something else I have running is causing interference.

Comment 5

[Jordan Gutterman]

Firefox's safe mode disables the JIT javascript engine, so I'm guessing that's the 20s difference between the two results. (I don't know why Safe Mode disables the JIT, but it does).

Comment 6

[Boris Zbarsky [:bzbarsky]]

Clint, I wonder... Are you using Kaspersky antivirus by any chance?

Comment 7

[Clint Priest]

Okay, I've confirmed its definitely my machine.  Vista Safe Mode runs 4 x 5000 in 893ms.  I've booted back into regular windows and shutdown every service and process that wasn't necessary to run windows and still got the same issue.  I can only assume it must be a driver at this point.  I've updated my nvidia drivers as that's my motherboard drivers as well, didn't help.

I do indeed run Kaspersky, I'll uninstall that and give it a shot as well.

I don't have a run of the mill desktop setup, I've got a quad core with 8GB of ram running Vista 64 Bit with 4 SAS drives running in RAID 5 and a memory stick for ReadyBoost.  In addition I've got 2 nvidia 8800 GTX's driving a 30" and two 21" monitors.

Add's some complexity there but any ideas spring from that?  I've confirmed it runs fine on my laptop (running vista 32 bit) in normal mode.

Comment 8

[Clint Priest]

There it is, Kaspersky was the culprit.  Getting 1605ms now on 4 x 5000.  Not surprising I guess that disabling Kaspersky didn't resolve the issue originally.

Is there a known issues w/ Kaspersky?

Comment 9

[Boris Zbarsky [:bzbarsky]]

> Is there a known issues w/ Kaspersky?

Yes.  See the discussion in bug 490794.

I've filed bug 522847 on the performance issue on this testcase when accessibility is enabled.  Leaving this bug open for the "5x slower than Chrome" issue.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Disabling reflow interruption makes it more like 3x instead of 5x, due to the way this testcase measures its times.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So there are two main things going on here.  Layout (about 60% of the time) and frame construction (the remaining 40%).

Of the css box model construction, a bit more than half is under nsStyleSet::FileRules (calling EnumRulesMatching, AddImportantRules, EnumPseudoRulesMatching) plus RuleProcessorData construction (this last is only about 7-10% of frame construction, though).  The rest seems to be actually creating frames, malloc, free, looking up the right buckets in the presshell arena, etc.

Of the reflow time, 1/10 is spent invalidating.  Another 1/10 is under nsTextFrame::Reflow.  4% is VerticalAlingLine (getting metrics, getting the centered font baseline, etc).  About 4% each in trimming trailing whitespace and storing overflow during RelativePositionFrames.  About 30% under nsHTMLReflowState::Init (mostly under column intrinsic width computation for the basic table layout strategy).  Most of the rest seems to be block reflow for the table cell blocks (including block reflow state construction and its line height computations), plus cell and row reflow.

Comment 12

[Clint Priest]

I went back to test my web application today and am still finding slow performance there with about 200 rows.  The test case I built still runs quickly.  If I build a test case closer to my actual problem would that be of benefit to you guys?

Comment 13

[Boris Zbarsky [:bzbarsky]]

Yes, absolutely.  Please file a separate bug and add me to the cc list?  Since the testcase here shows problems as well, just not the ones you're seeing, it's better to keep track of the two issues separately.

Thank you for your patience!

Comment 14

[Clint Priest]

Your welcome, just entered the bug and test case #2 for the other issue, bug 522930.

Comment 15

[Florian Bender]

Both Firefox 25b9 and Nightly 27.0a1 (2013-10-18) are ~75% slower than Chrome 30 (regression found in Bug 522930 Comment 20 does not seem to affect this case).

Comment 16

[Boris Zbarsky [:bzbarsky]]

Attachment: The testcase, just so it won't go away

Comment 17

[Boris Zbarsky [:bzbarsky]]

At this point, frame construction is down to 30%; layout is at 70%.

For the frame construction, about 1/3 is resolving style for the table cells (including SelectorMatchesTree calls!).  Most of the rest is constructing the actual table cell boxes, checking for before/after content, etc.

On the layout side, 20% is computing the intrinsic widths of the table; 2/3 of this is textrun construction.  The rest seems to mostly be block/inline reflow for all those cells.