Also wanted to add that while innerHTML will get faster only incrementally, the DOM approach actually benefits from the VM getting faster (which is where all the focus is on optimization these days).
On Thu, Apr 16, 2009 at 2:26 PM, Vitali Lovich <vlov...@gmail.com> wrote: > > > On Thu, Apr 16, 2009 at 1:22 PM, Jason Essington < > jason.essing...@gmail.com> wrote: > > > > oops, my bad, you are talking about the grid example ... > > > > This is overly simplified, but ... > > > > Well lets look at what is happening. every time you create a widget, > > you instantiate a javascript object, that object has fields and > > methods to support widget behavior, so more javascript object > > instantiation, you also call Document.createElement() to create the > > element that will ultimately be inserted into the DOM ... now you do > > this multiple times because composite widgets are rarely just a single > > widget. All of this stuff is done in an interpreted dynamic language ... > This is only bad with a crappy interpreter. Seriously, Webkit, Gecko & > Presto just cream IE7 (IE8 numbers don't seem to be available, but I don't > hold much hope) & the new iterations are several times faster than that. > > In fact, it appears that aside from IE, DOM is actually > faster<http://andrew.hedges.name/experiments/innerhtml/>* > than innerHTML > > * Caveat - I don't endorse the testing methodology because I haven't > reviewed it, so it may be bunk. Nevertheless, it does appear that the > common wisdom of using innerHTML may be a holdover. Now obviously widgets > are more heavyweight than the DOM manipulations he's using, so I'm not sure > what the impact of that is. > > > > > Now, getInnerHtml() -> setInnerHTML() no objects are created in > > javascript, (well, ok one string is created by the getInnerHTML call) > > a single DOM method call is made that passes text to the underlying > > browser rendering engine (usually compiled C of some sort) that engine > > renders the html and you are done. > > > > Though there have been great strides in Javascript engine performance > > in the last year, they still are nowhere near the performance of > > compiled C code. > Depends on what you're doing. I'm pretty sure that the overhead of parsing > HTML in C is far greater than simply modifying a few pointers here or there > in JS. > > > > > > -jason > > > > > > On Apr 16, 2009, at 10:55 AM, Vitali Lovich wrote: > > > >> How is this different than building up the HTML structure using > >> widgets as I mention above? > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
