No it's not necessarily linear (although I expect that it is actually fairly linear). But I think you're missing the larger point which is that the performance is going to be extremely similar since you're only going to create the grid once with DOM (1.5x isn't that much & as you can see, a faster JS engine can actually make the DOM faster).
innerHTML is not inherently faster - I'd argue it's inherintley slower, we just had (unnecessarily) crappy JS performance historically (thank you Apple & Google for really lighting a fire under everyone). I think there's still room for improvement - there's no reason JS performance can't approach native or even surpass like Java does (except for the initial overhead of parsing & compiling the JS). For that though I think GWT is perfectly positioned because it's cached per-browser js can be compiled by the browser into an intermediary form & cached until a new version of the app is available. As has been shown, JIT for javascript is still at the early stages - there's still large performance gains to be had. 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 -~----------~----~----~----~------~----~------~--~---
