Have we evaluated why it is so slow on ie8? It might be easier to fix that. The one thing it does is heavy use of StringBuffers so that could be where the issue is. On Jun 12, 2013 8:09 PM, "Brian Slesinsky" <skybr...@google.com> wrote:
> Lazy parsing can be a performance win, but it also complicates the API in > the case of a parse error. Have you thought about how to report errors when > they happen later? > > It might less confusing to solve this using a separate LazyBigDecimal > class. People can declare fields of this type in their data transfer > objects when they're concerned about performance. > > > On Tue, Jun 11, 2013 at 1:56 AM, stuckagain <david.no...@gmail.com> wrote: > >> Hi, >> >> I am working on a fix for this issue: >> https://code.google.com/p/google-web-toolkit/issues/detail?id=8083 >> >> I am avoiding converting from string to the internal format of BigInteger >> because it has a big performance impact on IE8 when sending it over RPC. It >> performs much better in IE9 and other browsers, but still I want to >> optimize this since this is having a major impact in an application I am >> working on (And I saw some other people in the banking industry having >> similar issues with BigDecimal). >> >> In many cases this data is never modified in the client, so I am delaying >> the actual parsing of the String to the internal format of BigInteger. >> >> Is it feasible to have custom field serializers depending on running in >> the client or server ? >> >> The question I am asking is because I don't want to break the >> BigInteger(String) constructor that will throw exceptions when you feed it >> a non parseable string. so my solution would be to use a static method or >> custom constructor for BigInteger when deserializing on the client. But >> this method is not available in the real java.math.BigInteger class. >> >> So is it possible to have different client and server >> serializers/deserializer code for RPC ? >> >> David >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> --- >> You received this message because you are subscribed to the Google Groups >> "GWT Contributors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "GWT Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
