Re: GWT RPC future ?
Hi, I guess they could improve by making these object lazy, that would provide a better synergy between runtime performance and serialisation performance. BigInteger and Long could keep a reference to the String representation (or something other efficient) and just convert to the internal representation when absolutely needed (when doing calculations). That is basically what I did for the BigInteger issue I had. But I just implemented my own BigInteger and custom serializer that just disable all methods except a few. I don't need calculations on these objects, but changing the 2000+ references is not an option - nobody ever listens to remarks of the GUI guys but we are always blamed when the appcation is not responsive. David On Monday, March 4, 2013 1:10:55 AM UTC+1, Evan Ruff wrote: Guys, On the heels of David's post, I was going through my application and noticed some poor RPC performance as well... much poorer than I remember. I went through my code and noticed that I'm using Longs in every object, as that's the default @Id for Objectify on AppEngine. Is there a simple way to get the GWT-RPC to serialized these differently by default? I'd really like to keep everything as is without having to swap out everything, as the Android and AppEngine Servlets are working great. Thanks! E On Tuesday, February 26, 2013 4:55:56 AM UTC-5, stuckagain wrote: People, Just to post some feedback on my problem, I actually found a working solution and I think there is a lesson in here that it warrant me writing back in this thread. I managed to implement my own custom serialisation based on the flickr post. I managed to double the performance and I implemented it so that I don't use recursion to make it possible to move to an incremental approach to avoid stack overflows. But x2 is still too long to be acceptable so I ran it through the IE9 profiler and I noticed that most of the time was actually spent in BigInteger and Long methods... That made me remember the discussion a long time ago that longs are emulated in GWT and we should avoid them unless absolutely needed. I switched to sending a byte array for these id fields and I got a 10x speed increase (and that is with the regular GWT serialisation, not my own version). I did not realize that Longs were that costly (on IE). So, that resolves the performance issue for me. Sure, another round of thinking is needed to avoid sending such large object trees in the first place, but this offers an acceptable solution for now - and since browsers like Chrome and FireFox (and even IE) are becoming much faster I might not even need to further improve it. David On Wednesday, February 13, 2013 5:31:10 PM UTC+1, stuckagain wrote: Thomas, I just read the article on how they improved parsing time in flickr ... really simplistic and a big surprise that the split trick is as fast as native json parsing! Would such an approach be usable for a generic object serialisation/deserialisation approach ? David On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of
Re: GWT RPC future ?
Guys, On the heels of David's post, I was going through my application and noticed some poor RPC performance as well... much poorer than I remember. I went through my code and noticed that I'm using Longs in every object, as that's the default @Id for Objectify on AppEngine. Is there a simple way to get the GWT-RPC to serialized these differently by default? I'd really like to keep everything as is without having to swap out everything, as the Android and AppEngine Servlets are working great. Thanks! E On Tuesday, February 26, 2013 4:55:56 AM UTC-5, stuckagain wrote: People, Just to post some feedback on my problem, I actually found a working solution and I think there is a lesson in here that it warrant me writing back in this thread. I managed to implement my own custom serialisation based on the flickr post. I managed to double the performance and I implemented it so that I don't use recursion to make it possible to move to an incremental approach to avoid stack overflows. But x2 is still too long to be acceptable so I ran it through the IE9 profiler and I noticed that most of the time was actually spent in BigInteger and Long methods... That made me remember the discussion a long time ago that longs are emulated in GWT and we should avoid them unless absolutely needed. I switched to sending a byte array for these id fields and I got a 10x speed increase (and that is with the regular GWT serialisation, not my own version). I did not realize that Longs were that costly (on IE). So, that resolves the performance issue for me. Sure, another round of thinking is needed to avoid sending such large object trees in the first place, but this offers an acceptable solution for now - and since browsers like Chrome and FireFox (and even IE) are becoming much faster I might not even need to further improve it. David On Wednesday, February 13, 2013 5:31:10 PM UTC+1, stuckagain wrote: Thomas, I just read the article on how they improved parsing time in flickr ... really simplistic and a big surprise that the split trick is as fast as native json parsing! Would such an approach be usable for a generic object serialisation/deserialisation approach ? David On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of annotation-processing at compile-time, for instance). 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. RequestFactory can easily be used in-process within
Re: GWT RPC future ?
People, Just to post some feedback on my problem, I actually found a working solution and I think there is a lesson in here that it warrant me writing back in this thread. I managed to implement my own custom serialisation based on the flickr post. I managed to double the performance and I implemented it so that I don't use recursion to make it possible to move to an incremental approach to avoid stack overflows. But x2 is still too long to be acceptable so I ran it through the IE9 profiler and I noticed that most of the time was actually spent in BigInteger and Long methods... That made me remember the discussion a long time ago that longs are emulated in GWT and we should avoid them unless absolutely needed. I switched to sending a byte array for these id fields and I got a 10x speed increase (and that is with the regular GWT serialisation, not my own version). I did not realize that Longs were that costly (on IE). So, that resolves the performance issue for me. Sure, another round of thinking is needed to avoid sending such large object trees in the first place, but this offers an acceptable solution for now - and since browsers like Chrome and FireFox (and even IE) are becoming much faster I might not even need to further improve it. David On Wednesday, February 13, 2013 5:31:10 PM UTC+1, stuckagain wrote: Thomas, I just read the article on how they improved parsing time in flickr ... really simplistic and a big surprise that the split trick is as fast as native json parsing! Would such an approach be usable for a generic object serialisation/deserialisation approach ? David On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of annotation-processing at compile-time, for instance). 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. RequestFactory can easily be used in-process within tests, and ships with a pure-Java client (usable on Android for instance). It comes with 2 dialects under the same API: its own RequestFactory protocol (JSON-based) that deals with batching of method calls and sending only diffs for entities, and JSON-RPC. The server-side component only supports the former dialect though, the latter is only about using existing JSON-RPC services (such as Google APIs) from a Java or GWT app. That said, I doubt RequestFactory would perform better for your 1 nodes use-case (I think we can even say it will perform much worse than RPC; this can probably
Re: GWT RPC future ?
Thomas, I just read the article on how they improved parsing time in flickr ... really simplistic and a big surprise that the split trick is as fast as native json parsing! Would such an approach be usable for a generic object serialisation/deserialisation approach ? David On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of annotation-processing at compile-time, for instance). 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. RequestFactory can easily be used in-process within tests, and ships with a pure-Java client (usable on Android for instance). It comes with 2 dialects under the same API: its own RequestFactory protocol (JSON-based) that deals with batching of method calls and sending only diffs for entities, and JSON-RPC. The server-side component only supports the former dialect though, the latter is only about using existing JSON-RPC services (such as Google APIs) from a Java or GWT app. That said, I doubt RequestFactory would perform better for your 1 nodes use-case (I think we can even say it will perform much worse than RPC; this can probably be improved by doing more codegen at compile-time and less reflection at runtime, but I'm not sure it'd even be better than RPC; this is mostly about the server-side though, and possibly DevMode too; it should be an all different story if you use the JSON-RPC dialect). An alternative to RPC and RF, using (a slightly modified) JSON-RPC protocol with an RPC-like API is gwt-json-rpc, used by Gerrit: https://gerrit.googlesource.com/gwtjsonrpc/ You'll find the JAR in a Maven repo at https://gerrit-maven-repository.googlecode.com/svn/ (Gerrit itself references https://gerrit-maven.commondatastorage.googleapis.comso I think the googlecode repo is an old one; the commondatastorage.googleapis one is not browsable though so it's hard to tell which artifacts are in there). Look at the README file for details. Finally, it's a bit old (almost 4 years old) but it should still apply as you're talking about IE: Flickr ditched JSON for a custom format for better performances, maybe you could do something similar: http://code.flickr.net/2009/03/18/building-fast-client-side-searches/ -- 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
Re: GWT RPC future ?
Thomas and Paul, Thanks for all the info, I will certainly look into these alternatives. The only problem is that somehow GWT should include a fast generic RPC mechanism. I hate having to depend on 3rd party alternatives that are often writen by one individual to solve his own issue and never maintained. I am writing banking software and we have some strict requirements on what products we are allowed to use since we have some very tight end-user licenses that requires us to fix issues very quickly. But somehow RPC is fundamental to AJAX apps build on GWT and it is a shame that we have almost no support for JSON-REST kind of APIs since that is what most people seem to be using. David On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of annotation-processing at compile-time, for instance). 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. RequestFactory can easily be used in-process within tests, and ships with a pure-Java client (usable on Android for instance). It comes with 2 dialects under the same API: its own RequestFactory protocol (JSON-based) that deals with batching of method calls and sending only diffs for entities, and JSON-RPC. The server-side component only supports the former dialect though, the latter is only about using existing JSON-RPC services (such as Google APIs) from a Java or GWT app. That said, I doubt RequestFactory would perform better for your 1 nodes use-case (I think we can even say it will perform much worse than RPC; this can probably be improved by doing more codegen at compile-time and less reflection at runtime, but I'm not sure it'd even be better than RPC; this is mostly about the server-side though, and possibly DevMode too; it should be an all different story if you use the JSON-RPC dialect). An alternative to RPC and RF, using (a slightly modified) JSON-RPC protocol with an RPC-like API is gwt-json-rpc, used by Gerrit: https://gerrit.googlesource.com/gwtjsonrpc/ You'll find the JAR in a Maven repo at https://gerrit-maven-repository.googlecode.com/svn/ (Gerrit itself references https://gerrit-maven.commondatastorage.googleapis.comso I think the googlecode repo is an old one; the commondatastorage.googleapis one is not browsable though so it's hard to tell which artifacts are in there). Look at the README file for details. Finally, it's a bit old (almost 4 years old) but it should still apply as you're talking about
Re: GWT RPC future ?
I too am very interested in this. I absolutely do not want to jump over to RequestFactory. I love GWT-RPC and I use it in conjunction with the Command Pattern action/result wrapper. I haven't seen any problems with GWT-RPC in terms of performance as I don't currently have any high payloads (except I do have one large payload that comes across soon after app load). So not a huge issues for me, but I also love to see higher performance especially when it is baked into gwt core. Although I do plan to explore gwtjsonrpc over the next few weeks. @paul, do you have sharable resources on your mechanism and possibly any suggestions?? Thanks! -at On Thursday, February 7, 2013 5:47:34 AM UTC-5, stuckagain wrote: Thomas and Paul, Thanks for all the info, I will certainly look into these alternatives. The only problem is that somehow GWT should include a fast generic RPC mechanism. I hate having to depend on 3rd party alternatives that are often writen by one individual to solve his own issue and never maintained. I am writing banking software and we have some strict requirements on what products we are allowed to use since we have some very tight end-user licenses that requires us to fix issues very quickly. But somehow RPC is fundamental to AJAX apps build on GWT and it is a shame that we have almost no support for JSON-REST kind of APIs since that is what most people seem to be using. David On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of annotation-processing at compile-time, for instance). 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. RequestFactory can easily be used in-process within tests, and ships with a pure-Java client (usable on Android for instance). It comes with 2 dialects under the same API: its own RequestFactory protocol (JSON-based) that deals with batching of method calls and sending only diffs for entities, and JSON-RPC. The server-side component only supports the former dialect though, the latter is only about using existing JSON-RPC services (such as Google APIs) from a Java or GWT app. That said, I doubt RequestFactory would perform better for your 1 nodes use-case (I think we can even say it will perform much worse than RPC; this can probably be improved by doing more codegen at compile-time and less reflection at runtime, but I'm not sure it'd even be better than RPC; this is mostly about the server-side though, and possibly
Re: GWT RPC future ?
There is always RestyGWT - http://restygwt.fusesource.org/ I've been using it recently and it works very nicely in combination with Jersey. I'm not sure on speed compared to GWT-RPC though, you'd need to test. I haven't had any speed problems so far though. RestyGWT will let you use raw json responses though, which should be very performant for your 10K nodes, while also letting you use java objects for regular requests. Using Jersey for your server also lets you create standard RESTful services that can be easily consumed by iOS clients/other websites/etc. On Thursday, February 7, 2013 12:47:34 PM UTC+2, stuckagain wrote: Thomas and Paul, Thanks for all the info, I will certainly look into these alternatives. The only problem is that somehow GWT should include a fast generic RPC mechanism. I hate having to depend on 3rd party alternatives that are often writen by one individual to solve his own issue and never maintained. I am writing banking software and we have some strict requirements on what products we are allowed to use since we have some very tight end-user licenses that requires us to fix issues very quickly. But somehow RPC is fundamental to AJAX apps build on GWT and it is a shame that we have almost no support for JSON-REST kind of APIs since that is what most people seem to be using. David On Wednesday, February 6, 2013 5:17:33 PM UTC+1, Thomas Broyer wrote: On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of annotation-processing at compile-time, for instance). 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. RequestFactory can easily be used in-process within tests, and ships with a pure-Java client (usable on Android for instance). It comes with 2 dialects under the same API: its own RequestFactory protocol (JSON-based) that deals with batching of method calls and sending only diffs for entities, and JSON-RPC. The server-side component only supports the former dialect though, the latter is only about using existing JSON-RPC services (such as Google APIs) from a Java or GWT app. That said, I doubt RequestFactory would perform better for your 1 nodes use-case (I think we can even say it will perform much worse than RPC; this can probably be improved by doing more codegen at compile-time and less reflection at runtime, but I'm not sure it'd even be better than RPC; this is mostly about the server-side though, and possibly DevMode too; it should be an all different story if you use the JSON-RPC dialect).
Re: GWT RPC future ?
Hi, Another option is the Restlet edition for GWT: - https://github.com/restlet/restlet-framework-java/tree/master/modules also take a look at piriti (http://code.google.com/p/piriti/wiki/Comparison) Cheers Rob Kiahu.com -- 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.
Re: GWT RPC future ?
On Wednesday, February 6, 2013 4:37:35 PM UTC+1, 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 1 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). Indeed RequestFactory can be used for generic RPC. Have a look at http://tbroyer.posterous.com/gwt-211-requestfactory and http://tbroyer.posterous.com/gwt-211-requestfactory-part-ii It's rather old and might be inaccurate in a few places (hasn't been updated for GWT 2.4's use of annotation-processing at compile-time, for instance). 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. RequestFactory can easily be used in-process within tests, and ships with a pure-Java client (usable on Android for instance). It comes with 2 dialects under the same API: its own RequestFactory protocol (JSON-based) that deals with batching of method calls and sending only diffs for entities, and JSON-RPC. The server-side component only supports the former dialect though, the latter is only about using existing JSON-RPC services (such as Google APIs) from a Java or GWT app. That said, I doubt RequestFactory would perform better for your 1 nodes use-case (I think we can even say it will perform much worse than RPC; this can probably be improved by doing more codegen at compile-time and less reflection at runtime, but I'm not sure it'd even be better than RPC; this is mostly about the server-side though, and possibly DevMode too; it should be an all different story if you use the JSON-RPC dialect). An alternative to RPC and RF, using (a slightly modified) JSON-RPC protocol with an RPC-like API is gwt-json-rpc, used by Gerrit: https://gerrit.googlesource.com/gwtjsonrpc/ You'll find the JAR in a Maven repo at https://gerrit-maven-repository.googlecode.com/svn/ (Gerrit itself references https://gerrit-maven.commondatastorage.googleapis.com so I think the googlecode repo is an old one; the commondatastorage.googleapis one is not browsable though so it's hard to tell which artifacts are in there). Look at the README file for details. Finally, it's a bit old (almost 4 years old) but it should still apply as you're talking about IE: Flickr ditched JSON for a custom format for better performances, maybe you could do something similar: http://code.flickr.net/2009/03/18/building-fast-client-side-searches/ -- 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.
Re: GWT RPC future ?
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 1 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.
