Closed Bug 568244 Opened 15 years ago Closed 9 years ago

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

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Platform:
Other
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugs, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

Attachments

(1 file)

Attached test of table creation.
4.51 KB, application/xhtml+xml
Details
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: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: