Forgot to mention this code-snippet I found in the BigInteger class:
/**
* The magnitude of this big integer. This array is in little endian
order and
* each "digit" is a 32-bit unsigned integer. For example: {@code 13} is
* represented as [ 13 ] {@code -13} is represented as [ 13 ] {@code 2^32
+
* 13} is represented as [ 13, 1 ] {@code 2^64 + 13} is represented as [
13,
* 0, 1 ] {@code 2^31} is represented as [ Integer.MIN_VALUE ] The
magnitude
* array may be longer than strictly necessary, which results in
additional
* trailing zeros.
*
* <p>TODO(jat): consider changing to 24-bit integers for better
performance
* in browsers.
*/
transient int digits[];
Always nice to have TODO's in code that are not done :-) Who is "jat" ?
David
On Thu, Jun 13, 2013 at 9:14 AM, David <[email protected]> wrote:
> 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.
