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 <zig...@gmail.com> 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 <vlov...@gmail.com> wrote: > > On Thu, Apr 16, 2009 at 1:27 PM, Pascal <zig...@gmail.com> 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 Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---