Not having a JIT may be really biting you here. AFAIK GWT serialisation makes extensive use of reflection, however there seems to be a way to define a custom field serializer (looks similar to using Externalizable), but I've not tried this myself:
http://books.google.co.uk/books?id=KXBdajKMJGEC&pg=PA164&lpg=PA164&dq=gwt+custom+field+serializer&source=bl&ots=w5LGABPcqR&sig=JRqZoeXztC7rG9jxftP_6QbbWwM&hl=en&ei=0syfSqSsIIPUjAf77Jm9Dg&sa=X&oi=book_result&ct=result&resnum=9#v=onepage&q=gwt%20custom%20field%20serializer&f=false Good luck and if you decide to try this approach I'll be interested to hear how you get on. Cheers, Chris. On Sep 2, 12:04 pm, David Given <[email protected]> wrote: > Chris Lowe wrote: > > [...] > > > 500-600 does seem like a lot of objects to be processing in one hit if > > performance on a low end server is a concern, but then again 20 > > seconds seems like an awfully long time too. > > Actually, thinking about it, it's more than that --- probably around > 1500 objects (500 large objects, but each one contains references to a > few small just-data objects). > > > What's the performance like in your dev environment? Are your JVM > > settings the same as those on your target server? > > [...] > > You can also add a simple filter before the GWT servlet to > > give you a very coarse request timing - you can at least then rule out > > latencies and bandwidth to your server. > > I wish. The target server is a solid-state ARM box -- a SheevaPlug > (1.2GHz processor, 512MB RAM). Alas, there is no decent JIT for ARM yet, > so it's running the interpreted JDK. I'll check out VisualVM, but I > suspect that it's not up to running it. > > Annoyingly the machine is perfectly capable of running the actual > *application*. The actual logic takes a tiny fraction of the time of the > serialisation. > > My development machine is a traditional ix32 box and serialisation takes > a trivial amount of time. I'll try the trick with the filter to get some > actual figures. > > [...] > > > How large are your serialized objects prior to compression? I think > > you can quickly test this by disabling gzip compression in FireFox: > > >http://forgetmenotes.blogspot.com/2009/05/how-to-disable-gzip-compres... > > This just causes the page to turn into garbage --- probably a server > misconfiguration on my end. > > > If the uncompressed size is particularly large then memory and > > compression time may be the limiting factor. > > Looking at the server stats its VM size doesn't appear to change during > the first serialisation process, indicating that it doesn't want to > allocate more memory. I have a feeling that memory's not the problem. > > > Finally, what kind of objects are you serialising? Are you attempting > > to send something like Hibernate objects over the wire (or some other > > kind of proxied objects) which are causing unexpected database hits? > > Nope. The entire DB is being held in-memory. In fact, the way my app > works is that the server logic calculates the delta needed to be sent to > the client, constructs a packet of client objects from this, and then > returns that packet as the result from the RPC call, so the stuff being > serialised doesn't actually content to the objects in the DB at all. (My > 400-object delta, the result of the initial DB sync, takes about 4s to > generate.) > > The delta generation uses reflection and annotations to query the DB > objects for properties that need to be copied into the delta. (The > client is only allowed to see information from the DB that the user is > allowed to have.) Simply by adding a cache for Field objects I managed > to reduce the time taken for the delta generation by a factor of ten, so > I suspect that reflection is dog slow with this JVM. What does the GWT > serialisation system use? If it uses reflection, is there any way of > persuading it to use byte-code generation instead? > > -- > ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────http://www.cowlark.com───── > │ > │ "They laughed at Newton. They laughed at Einstein. Of course, they > │ also laughed at Bozo the Clown." --- Carl Sagan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
