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
-~----------~----~----~----~------~----~------~--~---

Reply via email to