You'll also want to note that 50x50 is a pretty small test grid compared to what we were talking about here, when the size grows, the time it takes isn't necessarily linear for the DOM object creation.
but I've got to say, the results are not what I would have expected on my machine with Safari 4! 2.66ghz MacPro with Safari 4 DOM 1: 7 ms DOM 2: 8 ms Table: 8 ms inner1: 16 ms inner2: 16 ms Firefox 3.0.8 is pitifully slow in comparison DOM 1: 88 ms DOM 2: 74 ms Table: 90 ms inner1: 36 ms inner2: 34 ms looks like Safari's new javascript engine is pretty damn zippy at creating DOM objects! who would have guessed? -jason On Apr 16, 2009, at 4:08 PM, Vitali Lovich wrote: > I dunno, I don't see anywhere near the difference the website claims > (average over 5 runs): > > on Q6600 @ 3.2 GHz > FF 3.5 b4: > > DOM1 65 ms > DOM2 65 ms > Table 69 ms > Inner1: 37 ms > Inner2: 39 ms > > FF 3.0.8 > > DOM1 86 ms > DOM2 73 ms > Table 80 ms > Inner1: 43 ms > Inner2: 42 ms > > Konqueror (don't have chrome or safari, but KHTML should be fairly > close to Webkit) > DOM1 25 ms > DOM2 21 ms > Table 24 ms > Inner1: 15 ms > Inner2: 16 ms > > On my laptop (Turion x64 @ 2.2 GHz) > > DOM1 125 ms > DOM2 112 ms > Table 141 ms > Inner1: 83 ms > Inner2: 80 ms > > So the DOM is slower in this test*, but not as significantly as > Arthur claimed (1.5x as opposed to 10-30x. However, considering the > amount of flexibility that is lost when building the HTML yourself, > I don't think it's justified. > > * Again not approving the methodology necessarily since I haven't > actually looked at what it does exactly. It has nothing to do with > who writes it but whether or not I understand what the test is doing > & I think it's doing a valid comparison (i.e. an objective metric). > > One thing I can think off the bat is that the way this code is > written, innerHTML can never lose. But it doesn't represent the > test case that was presented (or even a realistic one). Consider > this situation: instead of setting just to a simple character (or > simple text) `*', use a slightly more complex HTML layout. > > <div class="foo">this is a <div id="abc" class="bar">complex</div> > inner HTML example<img src="some raw base 64 image"</img></div>. > > Also, to make it more realistic, have random values set for complex > so that you have to generate the string randomly each time. I'm > quite confident that you'll see, all of a sudden, DOM & probably GWT > widgets, show no performance difference whereas the innerHTML will > get more expensive (slower than using DOM or GWT). I'll write a > test case sometime later if I feel like it. > > Again all of this excludes IE which is a crap browser when it comes > to standards or performance. I"m on Linux, so I can't test the > other browsers (don't feel like rebooting). > > On Thu, Apr 16, 2009 at 5:09 PM, Pascal <[email protected]> wrote: > > A bit in denial are we? Here are raw numbers for you. > > http://www.quirksmode.org/dom/innerhtml.html > > YO > > On Apr 16, 2:14 pm, Vitali Lovich <[email protected]> wrote: > > On Thu, Apr 16, 2009 at 1:27 PM, Pascal <[email protected]> wrote: > > > > >> > Creation of individual DOM elements in javascript seems to be > pretty slow > > >> > (it is a bit faster in the new generation browsers ff3, > Safari4 and chrome) > > >> > but setInnerHTML() doesn't create those elements in > javascript, it is done > > >> > natively in the browser and thus is much faster. > > > > >> I'd need to see a benchmark that that is indeed the case. I > don't > > >> have time right now (I'll experiment later if I have the > chance). But > > >> it seems wrong that creating the DOM elements in javascript is > slower > > >> than having the browser do it natively (the cost of modifying > the DOM > > >> should be the dominant factor by far). > > > > > Seriously, this is not even close. In IE for a table as small as > 50 > > > rows with 15 columns, you're looking at a few seconds with the > DOM and > > > below 100ms with innerHTML. (on a dev laptop here anyway). > > > > Me thinks there might a problem with your testing methodology. > First > > I think you're not taking into account the building of the string > > whereas you do time the widget creation. Secondly, if you have a > > constant 50 rows & 15 columns, see how long it takes to set the data > > once you've pre-created your widgets (this should actually be > faster I > > think than innerHTML if you have HTML elements there). > > Thirdly IE is the slowest browser (Javascript is actually > notoriously > > slower - not sure about DOM, but even that is still slower than any > > other browser). At least tell me you're testing with IE7 (which is > > still what, 2x slower than FF3.0 & 5 times slower than FF3.5). > > Fourthly, I'd prefer to use something like Firebug's profiling > rather > > than trying to instrument my own code - it's far less likely you'll > > make a mistake or misinterpret the data I think. > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
