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 <-lord...@web.de> 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 <bobwazn...@gmail.com> wrote: > > > Have you tried using a List instead of an array? > > > On Mar 26, 2:46 am, -Lord-67 <-lord...@web.de> 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 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 -~----------~----~----~----~------~----~------~--~---
