Hi, The lazy parsing would only happen during deserialisation in the client. I think it is safe to assume that a BigInteger created through toString on the server will not result in a parse exception in the client code - or are there known incompatibilities ?
I don't want that the regular constructor of BigInteger( String ) or BigInteger( String, int) would behave differently than before. Not even in the client when those BigInts are created in the client. That's why I was asking about the possibility to have different serialisers on client and server side. As the why, well currently the custom field serializer converts the BigInteger to a String, the client side needs to parse the string and convert it to an int array, which involves multiple substring, Integer.parseInt and multiply and add operations. Somehow IE8 has a problem with this. IE9 and other browsers are more efficient, but still that is a lot of CPU operations that can be avoided in my use case. In my particular use case they used BigInteger to represent a key in the database (oracle uses sequence numbers that are bigger than what can be represented with long). That might have not been the best idea, but those decisions have been made a long time ago, when I was not around. On the server side there is a usage of equals and compareTo happening, which would be hard to implement without a BigInteger, so there is logic in the choice. They obviously don't want to have an extra layer of objects to avoid the BigInteger in the GWT client since a lot of code is independent of client or server, this would hinder code sharing between the tiers. On the client side these id's are only send forth and back between client and server, no operation is ever performed, so making the custom field serialiser and the BigInteger cooperate gives a big performance improvement. They only operation needed on the client-side is equals, which can also be optimized to do a String comparison when bother have not been parsed after RPC. David On Thu, Jun 13, 2013 at 2:30 AM, John A. Tamplin <[email protected]> wrote: > 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" <[email protected]> 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 <[email protected]>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 [email protected] >>> . >>> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
