Hi gregor, thank you for this detailed answer.
First: I'm not sure if i understood everything since english is not my first language as you might have noticed. Sorry if i misunderstood something, i do my best. You're right what belongs the selection of data structure. I tried that and it makes no difference using a String[] or a ListArray of Strings to use as return value for the RPC. I know that rendering thousands of items takes some time, but that's not what i do with the data. I already use a model like you described in "FastTree". I just fetch all the data (in my case paths to images in a String[]) from the server via RPC and show the user just 10-50 pictures per page. I create only 10 images (100px*100px) + a paging menu (first tab) and 2 tables(grids with fix size) (second, third tab). In my opinion rendering these few items (say max. 50) is not the problem, right? The kind of model you described as "LazyLoad" is something i also thought of, but i liked the idea of waiting one time for about 3 seconds and working on this set without having to wait any more (this is what my users would like most). That's why i haven't tried it so far. I already measured the RPC call round trip time, think i haven't said that clearly enough in my first post: -> Starting the RPC (sending search parameters via RPC to the server): (no time i could measure in ms -> 0ms) -> server gets data per SQL statement and puts it into a String[] (the return value of the RPC): This step takes less than 200 ms [i measured the time from the start of RPC on server until the last statement, before "return myStringArray;" ] -> server serializes the data and sends it to client which deserializes it: This step takes about 5 SECONDS [i measured the time from sending the RPC to the server until i got the first answer on the client with "onSuccess()" and substracted the 200ms ] -> client saves the data in a lokal String[] and uses some of them to load and render 10 pictures and 2 tables: This step takes 1.2 seconds [i measured the time from "onSuccess()" beginning to the end ] So i am no step forward so far, but: I think i didn't test it in web mode for a long time (why should i, everything was fine on hosted and on web mode in the beginning and hosted mode is much easier for a quick test) so i will try that and hope it solves the problem. I will tell you the results on monday since i am not working the next two days. Thanks all for the help so far! Greetings, -Lord-67 On Mar 27, 2:00 pm, gregor <[email protected]> wrote: > Hi Lord-67 > > I don't think your selection of data structure for the data transfer > will make nuch material difference. > > Your observation that 500 strings works hunky dory, but 10,000 doesn't > is pretty much my experience. The issue is divided into two parts: > first the time taken to assemble, serialize and then deserialze the > List of objects. Second the time taken to render the objects in a > widget. You may not know this but it takes browsers an appreciable > amount of time to render thousands of items - each one has to have a > number of HTML "boxes" drawn for it. Test this yourself by making a > simple test Tree created from some nested for loops on the client, and > you will see that once you get up to 1500 or so TreeItems it starts to > slow down noticably, and round about 5000 it takes seconds to draw. > Note also different browsers give different performance in some > situations, so you need to consider that too. > > Another important thing is that RPC is *much* slower in hosted mode > than it is deployed in web mode (in case you haven't rumbled that > yet). > > You can try two approaches to solve this: the classic "lazy load", and > the "FastTree" approach. > > In the lazy load approach you fetch only a screen full of items at a > time (in a tree you would get just the top level items etc). next link > fetches the next batch. This usually produces a response time from the > user's perspective of <0.5s, which for them is a good as "instant". > Therefore although technically each page flip is slow (involving a > fresh RPC call for each page) it is not perceived as such, the user > does not have to wait seconds for the data to load. > > In the fast tree approach you fetch all the data in one RPC call, but > only actually draw screen full at a time, using the full list as a > backing model instead of making a fresh RPC call for each page. This > makes navigating the items in the UI very fast once the data model is > loaded because only the visible HTML boxes required are actually > drawn, but you pay a pre-loading price up front in the big RPC call. > > Which is best depends largely on your application and user > requirements and also on the precise time it takes to fetch the entire > list over RPC. For example if your users will routinely want to sort, > filter or search through a large data set in complex ways, then they > will probably thank you for implementing the fast tree idea and be > happy to wait maybe 2 or 3 seconds to fetch the all data up front > because the subsequent operations will be much faster. On the other > hand if a 10000 item list is unusual, or they would normally only be > interested in first page of two (typical for search results for > example) then the classic lazy load is almost certainly best as it > gives them a much quicker render of the first screen full. > > I'd say the first thing to do is to is to time your RPC call round > trip separately from your screen render times to get a feel for the > numbers, but do this in web mode either over web or on LAN, whichever > is appropriate for your typical user, in a selection of popular > browsers. > > regards > gregor > > On Mar 27, 10:35 am, -Lord-67 <[email protected]> wrote: > > > No, i haven't tried that so far, i will do so and let you know if it's > > getting better. Maybe a List needs less time to be serialized and > > deserialized. > > > Greetings, > > -Lord-67 > > > On Mar 26, 6:27 pm, lukehashj <[email protected]> wrote: > > > > Have you tried using a List instead of an array? > > > > On Mar 26, 2:46 am, -Lord-67 <[email protected]> wrote: > > > > > First of all: Hi to everyone! > > > > > I'm new to GWT and just programming my first app. Since i've some > > > > experience in Java it's not a big problem, but in this case i am stuck > > > > and hopefully someone can help me. > > > > > In my app i make a RPC: On server side i get some data out of a > > > > database and save it into an array of type String. Up to 10.000 > > > > Strings atm, later on maybe up to 50.000. It is no problem so far. The > > > > server is handling this really fast. I measured 5 RPCs with about 500 > > > > Strings each and it took less time than 200 milliseconds each (SQL > > > > Statement + creating the array). > > > > > The problem now is: I have to wait 5 SECONDS to get the results of the > > > > RPC (the String[] created on the server) on the client side so i can > > > > do something with them. Regarding the overall time i measured, these 5 > > > > seconds are more than 75% of the time which my app needs. Is it > > > > possible that the serialization and deserialization takes that much > > > > time? I don't think so and i have no clue where this 5 seconds come > > > > from. If someone has any ideas, solutions, suggestions on this problem > > > > i would appreciate any help! > > > > > Thanks in advance, > > > > -Lord-67 > > > > > P.s.: Of course i searched for a solution for this problem for hours, > > > > if i somehow just typed the wrong keywords to get the fitting results, > > > > just let me know and post a link :-). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
