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 <[email protected]> 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 <[email protected]> wrote: > > > thank you all for your advices... i learn something new again > > today..... :D > > > On Apr 15, 11:11 pm, Jason Essington <[email protected]> > > 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 [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 -~----------~----~----~----~------~----~------~--~---
