We had similar issues with RPC especially on the iPad. In the end I wrote a new RPC mechanism based on the command pattern that is entirely JSON based. The client representation of server side java objects are JSO's that are automatically maintained by a generator (outside of GWT). The RPC framework uses Jackson on the server for converting the Java objects to JSON.
Our system also does batching and client side caching (controlled by java annotations). The end result is I no longer worry about performance, even for large and complex payloads. The downside is that the client representation isn't the same as the server and you have to deal with JSO's. Debugging wasn't as nice because you couldn't inspect JSO's. That was until SuperDevMode came along and now its fine. If you don't want to go to that extreme, for specific slow calls you could just pass back json and parse it on the client and access the objects as JSO's. Alternatively, you could try one of the GWT REST frameworks. On Wednesday, February 6, 2013 10:37:35 AM UTC-5, stuckagain wrote: > > Hi, > > Not sure where to ask this question, but I was wondering if the GWT devs > every plan to fix the inefficient GWT-RPC ? > The problem happens mostly on IE (all versions), although I assume other > browsers might benefit as well since a lot of cpu cycles are wasted on > things that should be trivial for a browser. > > I had to improve multiple GWT apps that all stumble on these 3 problems: > - deserialisation is terribly inefficient - it can take many seconds to > serialize small sets of data, > - on IE I can get slow script warnings > - I sometimes get stack over flows with deeply nested structures. > > For example when I send over a tree of 10000 nodes (takes 20ms to create), > it takes 5 seconds or more to deserialize. (I can give you a demo app that > shows the problem) > > I only get 2 seconds to impress my users, and I need to do quite a lot of > operations besides sending the RPC. > > I've heared the reactions multiple times: don't send soo much data over, > but bytewise this is not soo much. It is highly compressible (just a few K > in fact) data. We want to process complex data structures in the client, we > don't want to create intermediate data structures to bypass the RPC > inefficiencies. > > There have been multiple attempts from google to write something better > (DeRPC whichi is now deprecated, and RequestFactory which is very badly > documented so I don't even know if I could reuse this one for generic RPC > calls). > > Is it not time to start using json as the base format for GWT RPC ? I > would even like to help out to get this working! It is really a pitty that > somehow RPC is a selling point for GWT but in reality it often becomes the > bottleneck of your application. > > Can't we maybe put GWT RPC on the framework for request factory ? > > One issue I also have with GWT RPC (but less pressing as the > performanceissue) is the fact that it is not very friendly for mixing > different client technologies. If it were a simple json REST payload > (without obfuscation and lots of secret numbers) then we could easily reuse > it everwhere, it would also make it soo much easier for loadtesting. Not a > lot of tools support GWT RPC easily. > > David > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
