I'm pretty sure that's wrong - inserting things into a table, detached or not, will still result, AFAIK, in DOM operations.
Anyways, if you never add the table to the screen, then it's never attached to begin with. Or do table.removeFromParent(). On Thu, Apr 16, 2009 at 2:23 AM, alex.d <alex.dukhov...@googlemail.com>wrote: > > How do you detach the table from the dom, assuming you can have it's > parent with table.getParent() ? > > On 16 Apr., 04:56, Arthur Kalmenson <arthur.k...@gmail.com> wrote: > > An easy thing you might want to try is to render the table detached > > from the DOM. This would ensure that you're not doing any DOM > > operations when building the table, which is generally very slow. That > > should be easy to implement if you grab the table's parent. > > > > -- > > Arthur Kalmenson > > > > On Wed, Apr 15, 2009 at 6:44 PM, ytbryan <ytbr...@gmail.com> wrote: > > > > > thank you all for your advices... i learn something new again > > > today..... :D > > > > > On Apr 15, 11:11 pm, Jason Essington <jason.essing...@gmail.com> > > > wrote: > > >> On Apr 15, 2009, at 8:51 AM,ytbryanwrote: > > > > >> > thanks for your reply thomas. for me, there is two cases of > slowness. > > > > >> > - the rpc is quite slow. i am using it to return a few thousand by > > >> > eleven column of data(String).... > > > > >> There are probably two issues here, one the speed of the RPC, and the > > >> second the speed of populating the table. > > > > >> But at issue is the attempt to return 33,000 cells worth of data in > > >> one shot. how much of this data is going to be immediately visible to > > >> the user? How likely is the user to use all of this data immediately? > > >> Does your use case present you the opportunity to fetch this data in > > >> some paged way? > > > > >> you need to figure out how much of your time is spent with the RPC > > >> (deserialization) and how much is spent rendering the table. I would > > >> be inclined to believe that you are likely to find that most of the > > >> time is actually spent rendering the 33,000 cells. however you do have > > >> some options here. > > >> You can move the rendering into an IncrementalCommand which will draw > > >> a few rows at a time which gives the appearance of a much more > > >> responsive application, and will begin rendering immediately, rather > > >> than waiting until all rows are populated before showing the data on > > >> screen. > > > > >> If your RPC data graph is pretty large, you could switch away from RPC > > >> and use a JSON data graph with Javascript Overlay types on the client > > >> side. a javascript eval() of the object graph from JSON is quite a bit > > >> (like orders of magnitude) faster than RPC deserialization with very > > >> large object graphs. NOTE your design shouldn't rely on large object > > >> graphs, paging is a much better option. > > > > >> And as gregor mentioned, if you are profiling your code in hosted > > >> mode, the performance has no correlation with real life. you need to > > >> check the performance in web mode, and remember that something that > > >> happens instantaneously in Firefox or Safari (or chrome) could take > > >> forever in IE (particularly IE6), its javascript engine operates at a > > >> glacial speed when compared to other options. > > > > >> > thanks again.. > > > > >> good luck > > > > >> -jason > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
