Hosted mode isn't particularly useful in determining how things will actually perform in "real life". It is useful for debugging, but the performance of certain operations tend to vary drastically from web mode. So, if you are testing your performance, you'll want to do it in web mode.
As for using large data sets, best to avoid that if you can. But there is a trick you can use if you determine that de-serialization on the client is your bottleneck. Rather than use GWT-RPC, you can use RequestBuilder to make the request, and simply return raw JSON data. On the client side you can use Javascript overlay types and simply eval() the result into an object. With very large data sets this technique can be orders of magnitude faster than regular RPC de- serialization. Another trick that might be useful would be to inject the JSON results into the host page, so that a second request isn't even required, then you can still use overlay types to access that data. -jason On Mar 27, 2009, at 8:43 AM, -Lord-67 wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
