I think the main question is how it perform in the various IEs. That's the browser you'll see 70% in the wild and 100% of the time in most corporate environments.
-- Arthur Kalmenson On Thu, Apr 16, 2009 at 6:23 PM, Jason Essington <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
