Closed Bug 568244 Opened 14 years ago Closed 8 years ago

Slow construction of large table using DOM calls. Twice as slow as innerHTML or Webkit

Categories

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

Other
Other
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bugs, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(1 file)

The linked page, which I will upload as a testcase, is a couple of years old.  Over that time, Firefox has made impressive improvements.  It used to take 2.5s on my machine using the first 2 buttons, 1.2s using the last.
It is now 0.95s and 0.45s or so.  Perhaps due to the new lazy frame construction.

The performance on innerHTML is comparable to Safari 4, but using DOM node creation is twice as slow in Firefox as it is in Webkit.

BTW, using cloneNode(true) on the initial row to create new rows gained about 0.2s, but cost about 0.2s in Webkit.

It seems that using node creation should be comparable in speed, if not faster, to innerHTML method, which in the real life case this was derived from, was not an option due to IE blowing up on innerHTML as well as the more complex nodes.
As a note, part of the issue is that jseng+quickstubs doesn't handle calling createTextNode with a number wel.  But even changing that (by passing in i+"") leaves us a good bit slower than Safari over here.

Smaug, how do things look with your createElement changes?
Blocks: domperf
The "Straight-forward node creation" drops on my machine from 0.8 to 0.55
after createElement changes. And pretty similar change also in the
"Straight-forward node creation, but no lastChild.lastChild" case.
That's with i+"" or without?
I was just testing the testcase in this bug
I'll try with +"" change
with +"" and createElement patch I get 0.31 in the first case and 0.33 in the second. 
innerHTML is 0.26
actually the values varies a bit.
First one 0.3 - 0.33 and the second 0.27 - 0.33

innerHTML is 0.25-0.27
And with +"" but without createElement patch
0.5 - 0.53, 0.45 - 0.47, 0.25 - 0.27
Nice!  That will pretty much land is in the range webkit is in, then.
Testing Mozilla/5.0 (Windows; Windows NT 5.1; rv:2.0b3pre) Gecko/20100723 Minefield/4.0b3pre
against
Safari 5.0  (7533.16)
On the same XP test machine as in the original bug, I get a basically unchanged Safari from 4 to 5.

            DOM     DOM no lastChild    innerHTML    
Safari 5    .478    .466                .349
Minefield   .784    .701                .437

So, about a 20% improvement over initial filing, but still about 55-60% slower than Safari.

Should I be testing a different Firefox browser?
The testcase uses the (still) slow createTextNode path.
i + "" should be faster.
And btw, on OSX I get similar results for innerHTML test using Minefield and Safari 5.
Thanks.  Is there a bug to follow for the remaining issue w/ createTextNode?
Yes; one of the spidermonkey bugs about THIS_OBJECT bailing off trace.
For what it's worth, at this point I see us (nightly) about the same as WebKit (Chrome dev channel) on the DOM version of that testcase, and a bit slower on the innerHTML version.
Depends on: 622298
So the numbers I see with a current nightly in the alerts are:

  node creation: 205ms
  node creation without lastChild: 178ms
  innerHTML: 147ms

For comparison, Safari (well, WebKit nightly):

  node creation: 376ms
  node creation without lastChild: 373ms
  innerHTML: 326ms

and Chrome dev:

  node creation: 172ms
  node creation without lastChild: 152ms
  innerHTML: 175ms

I have no idea how Chrome manages to be so much faster than Safari here...

In any case, looks to me like the bug as filed is fixed.  I'll do another profile just to see what the story is with us still being slower than Chrome, I guess.
Some of it is just the fact that Document is not on WebIDL bindings yet.  Some is just random slowness in createElement and createTextNode...  no obvious hotspots.
Aight.
I just reran on a different linux machine over here.  I took the best of 3 runs.  So, for example, 383ms was fasted Firefox Nightly, although there was a 469ms one.  Firefox was tested in a new profile. 
One odd thing is that Chromium seemed a bit snappier in displaying the final table, even when the times were close?  Faster rendering?

Chromium 24
348ms DOM 
356ms DOM no lastChild
265ms innerHTML

Firefox Nightly
383ms DOM
366ms DOM no lastChild
373ms innerHTML

Firefox 19
652ms DOM
619ms DOM no lastChild
405ms innerHTML


So. Firefox stable is still twice as slow as Chromium stable on this.
But Firefox nightly appears to be very close to Chromium apart from on innerHTML - but then, I didn't want to use innerHTML anyway 'cause in this case IE was particularly sucky at it at the time, and we still need to support IE8.

Closing it.  Up to you guys I guess.  Comparing stable against stable, the initial bug comment is still true.  Nightly Firefox against stable Chromium, apart from innerHTML they are well within eyeballed margin of error from the varying times I got.
> So. Firefox stable is still twice as slow as Chromium stable on this.

Right; 19 is still on the old DOM bindings.  You want to be testing 20 or later.

It's interesting that you see slower times in Firefox for innerHTML while I see much faster times (on Mac).

The actual display is probably layout; you could time that by forcing a layout flush before measuring the end number.  Might be interesting...
So, based on bz's suggestion on my Linux machine, running the 3 buttons in order, refreshing page to run the next one.
Firefox Nightly (20130610)
0.263
0.251
0.219

Chromium 25
0.199
0.194
0.184

Opera 12
0.441
0.373
0.137

And, after adding a layout flush...
Firefox Nightly (20130610)
2.989
2.931
2.857

Chromium 25
1.627
1.882
1.667

Opera 12
1.387
1.276
1.036

Layers accel made no difference.
Now, that, I guess, is a different bug.
On the table *construction* front, Firefox is still behind Chromium tho. Although not by as huge a margin.
Oh, and kinda weird.  If I do, say, (2.857-0.219=2.638) to try and get Firefox' innerHTML layout time, and
(2.931-0.251=2.680) for 2nd DOM, Those 2 values (innerHTML vs 2nd DOM) differ by 42ms.
Oddly, without the layout time, the innerHTML vs 2nd DOM times of 0.219 vs 0.251 differ by 32ms.

I'd expected w/ construction cancelled out that I should have gotten closer to, oh, <10ms instead of 42ms.
Noise? But Firefox is consistently slower on DOM as opposed to innerHTML.

By contrast, if I do the same thing with Opera...
(1.036-0.137=0.899) for innerHTML and (1.276-0.373=0.903) for 2nd DOM, I get a difference of 4ms.
Which is as I would expect.
Without the layout time, Opera's DOM was 236ms slower than innerHTML.  Bit of a shame that.  Esp since innerHTML was 
not an option even if it wasn't blowing up older versions of IE.

Anyway, overall...

Layout:
Firefox = ~2.7 seconds
Chrome  = ~1.6 seconds
Opera   = ~0.9 seconds

On this Linux machine, anyway.
> Noise? But Firefox is consistently slower on DOM as opposed to innerHTML.

Pretty odd.  Mind filing a separate bug with a testcase that measures the relevant times, just so I can make sure you and I are looking at the same thing?
Hum. Not tooootally sure what you mean by that :-/
Measures the relevant times?  There's already a testcase attached to this bug.
You mean one for the layout stuff?
Anyway. The extra layout force was tossed into http://m8y.org/tmp/testcase73c.xhtml
I mean a testcase that measures the "layout time" that you're seeing be slower for the "dom" case than the "innerHTML" case.
On the attached testcase:

Nightly 48
node creation: 324 ms
node creation without lastChild: 279 ms
innerHTML: 253 ms

Chrome 49
node creation: 349 ms
node creation without lastChild: 356 ms
innerHTML: 246 ms


On the testcase with layout flush:

Nightly 48
node creation: 4018 ms
node creation without lastChild: 3737 ms
innerHTML: 3703 ms

Chrome 49
node creation: 3621 ms
node creation without lastChild: 3628 ms
innerHTML: 3446 ms

I noticed Chrome pops up the result before showing the table - don't know if it matters.
Excellent.  Sounds like we're basically there (modulo some layout stuff, perhaps).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.