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 -~----------~----~----~----~------~----~------~--~---
