On Thu, Apr 16, 2009 at 7:07 AM, Thomas Broyer <[email protected]> wrote:
> > > > On 16 avr, 11:50, Vitali Lovich <[email protected]> wrote: > > On Thu, Apr 16, 2009 at 4:58 AM, Thomas Broyer <[email protected]> > wrote: > > > > > On 16 avr, 08:30, Vitali Lovich <[email protected]> wrote: > > > > I'm pretty sure that's wrong - inserting things into a table, > detached or > > > > not, will still result, AFAIK, in DOM operations. > > > > > ...but DOM operations on a detached tree is much faster because it > > > cannot cause a reflow or repaint (same for display:none DOM subtree). > > > See > > >http://ajaxian.com/archives/browser-reflows-how-do-they-affect-perfor. > .. > > > > I think you need to re-read that. That applies to CSS not Javascript. > > Since Javascript is single-threaded (even with HTML5, DOM manipulation > can > > only happen on 1 thread so this is still correct), these will not (at > least > > they shouldn't from what I understand of browsers) trigger any reflows or > > repaints until the browser gets control back (when you finishing making > all > > your DOM updates or if you use incremental commands). > > > > Thus you shouldn't see any performance benefits over inserting into a > > detached node or an attached node. > > http://ejohn.org/blog/dom-documentfragments/ > and > http://www.slideshare.net/julien.lecomte/high-performance-ajax-applications > (slide 33, for example) > (and many other web resources) proves you're wrong. I don't believe that it does. All it says is that DOM manipulation will cause a reflow, which I haven't disagreed with. I'm disagreeing with your assertion that every single DOM manipulation in a single Javascript execution block will cause a reflow. You seem to be saying that: tree t = new tree() t.addItem("abc"); t.addItem("def"); RootPanel.get().add(t); will have fewer reflows than tree t = new tree() RootPanel.get().add(t) t.addItem("abc") t.addItem("def") According to you (at least from what you've said so far) is that the 1st snippet will cause 1 DOM reflow whereas the below snippet will cause 2, which isn't actually the case AFAIK. Both will only cause 1 & will be equally fast. Now if you are doing this in an incremental command, then I don't disagree, although the number of reflows will be the number of times each invocation of the incremental command modifies the DOM. Although with incremental commands, progressive display may be more important than the slower overall rendering time depending on the size of the data & what the context is). > > > > > and in general the articles inhttp://ajaxian.com/by/topic/performance > > > (you'd have to understand GWT internals to make use of some of the > > > advices; for instance, queueing [1] maps to GWT's DeferredCommand --do > > > not forget to push "pause" in the command queue-- and > > > > I believe that pauses aren't strictly necessary unless you know you > > absolutely need them because the information in the DOM won't be > available > > until the next iteration of the event loop (I'm not 100% sure on this, so > I > > could be very wrong). > > All deferred commands are run in the same "timer tick" until a pause > is seen. So queuing 3 DeferredCommands in a row without pause won't > have the desired effect. > > > > IncrementalCommand; and the memoizer can hardly be done as proposed > > > > Memoization is simply a technique for caching results of expensive > > calculations - language independant concept (even if expressed > differently) > > yes, hence my "as proposed" (I meant, using the code from the article, > or similar code) > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
