Re: [gwt-contrib] Issue 8083, needs some input from GWT team
Hi, Theoretically you are absolutely right. But practically is another discussion, I am talking about thousands of lines that need to change just for the GUI tier limitations. The GUI is just a fraction of the application because the same Request/Response objects are used internally as well (command pattern). Redesigning the entire application because of a limitation of the GUI is nuts. But in the way we use BigInteger, I understand your point of view. But the same problem is there with BigDecimal (somebody else filled an issue so I did not bother to create a duplicate, it is marked as assume stale). We show records with BigDecimal in Cell tables. Again RPC is slow here. While the user will only click on certain records to make modifications. Again I could refactor to wait with conversion to BigDecimal until the user changes a value (to validate), but in this case BigDecimal was the right data-type to use and it is not nice to have to redesign an application because the RPC system of GWT has limitations. David On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky skybr...@google.comwrote: I agree; this seems like a workaround for one application that picked the wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? If someone wants to do some performance tests of GWT-RPC serialization, publishing the results would be useful to the community. My recommendation in this case would be create a new class named Id or Key that simply contains the BigDecimal, then modify the code to use it, then change the implementation to store the data in a string field instead. In the end you'll have more readable code. - Brian On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote: John, Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. The Oracle JDBC drivers return a BigInteger if you force it to the extremes. Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. David On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: 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. I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
Okay, fair enough. Making BigDecimal deserialize faster would certainly be a good thing. I just don't want it to result in hard-to-diagnose errors if there's some kind of mismatch between client and server. If there's any difference then we should probably have a configuration property or an annotation on the remote service interface to turn laziness on. On Fri, Jun 14, 2013 at 1:02 AM, David david.no...@gmail.com wrote: Hi, Theoretically you are absolutely right. But practically is another discussion, I am talking about thousands of lines that need to change just for the GUI tier limitations. The GUI is just a fraction of the application because the same Request/Response objects are used internally as well (command pattern). Redesigning the entire application because of a limitation of the GUI is nuts. But in the way we use BigInteger, I understand your point of view. But the same problem is there with BigDecimal (somebody else filled an issue so I did not bother to create a duplicate, it is marked as assume stale). We show records with BigDecimal in Cell tables. Again RPC is slow here. While the user will only click on certain records to make modifications. Again I could refactor to wait with conversion to BigDecimal until the user changes a value (to validate), but in this case BigDecimal was the right data-type to use and it is not nice to have to redesign an application because the RPC system of GWT has limitations. David On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky skybr...@google.comwrote: I agree; this seems like a workaround for one application that picked the wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? If someone wants to do some performance tests of GWT-RPC serialization, publishing the results would be useful to the community. My recommendation in this case would be create a new class named Id or Key that simply contains the BigDecimal, then modify the code to use it, then change the implementation to store the data in a string field instead. In the end you'll have more readable code. - Brian On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote: John, Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. The Oracle JDBC drivers return a BigInteger if you force it to the extremes. Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. David On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: 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
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
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 j...@jaet.org 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 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.comwrote: 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
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
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.
*
* pTODO(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 david.no...@gmail.com 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 j...@jaet.org 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 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.comwrote:
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
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
On Thursday, June 13, 2013 9:18:23 AM UTC+2, stuckagain wrote:
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:
{...@codejavascript:13} is
* represented as [ 13 ] {...@code javascript: -13} is represented as
[ 13 ] {...@code javascript: 2^32 +
* 13} is represented as [ 13, 1 ] {...@code javascript: 2^64 + 13}
is represented as [ 13,
* 0, 1 ] {...@code javascript: 2^31} is represented as [
Integer.MIN_VALUE ] The magnitude
* array may be longer than strictly necessary, which results in
additional
* trailing zeros.
*
* pTODO(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 ?
jat == John A. Tamplin
--
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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
On Thu, Jun 13, 2013 at 3:18 AM, David david.no...@gmail.com wrote:
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 ] {@code2^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.
*
* pTODO(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 ?
So where else should TODO's go? Clearly this is something that was
intended for future exploration - would you prefer there be nothing there
at all?
--
John A. Tamplin
--
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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: 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. I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only sending strings to the client rather than BigDecimals, if they client never does anything with them but send them back? I think it is going to be pretty rare in normal situations that you instantiate a BigDecimal but never actually use it in the client, so it seems the special-case hack for your use-case should be performed in your code instead. Too often people want to send things to the client that really don't belong there, and that includes particular representations of it. I know DTOs are extra work over just shipping your regular objects over the wire and GWT RPC makes that easy, but in many cases it is the wrong thing to do. Think about if you were building a proto for the communication -- would you send the data in the current form? If not, you shouldn't be sending it that way via RPC just because it is easy to do so. BTW, I thought Oracle sequence numbers did fit in long (aren't they int64?) -- at least all the JDBC code I see for manipulating them stores them in a Java long. -- John A. Tamplin -- 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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
John, Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. The Oracle JDBC drivers return a BigInteger if you force it to the extremes. Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. David On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: 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. I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only sending strings to the client rather than BigDecimals, if they client never does anything with them but send them back? I think it is going to be pretty rare in normal situations that you instantiate a BigDecimal but never actually use it in the client, so it seems the special-case hack for your use-case should be performed in your code instead. Too often people want to send things to the client that really don't belong there, and that includes particular representations of it. I know DTOs are extra work over just shipping your regular objects over the wire and GWT RPC makes that easy, but in many cases it is the wrong thing to do. Think about if you were building a proto for the communication -- would you send the data in the current form? If not, you shouldn't be sending it that way via RPC just because it is easy to do so. BTW, I thought Oracle sequence numbers did fit in long (aren't they int64?) -- at least all the JDBC code I see for manipulating them stores them in a Java long. -- John A. Tamplin -- 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
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only sending strings to the client rather than BigDecimals, if they client never does anything with them but send them back? Thats exactly what I thought too. If its just a database key then transform it on server side to something that does not cost you performance on client side. We also use GWT-RPC and all our database ids are converted to base64 strings before they go to the client. Works pretty well. -- 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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
On Thu, Jun 13, 2013 at 3:03 PM, David david.no...@gmail.com wrote: Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. I'm just one person and I'm not even on the steering committee, so you shouldn't take my opinion as gospel. To summarize, I don't think there is any value in having lazy initialization of BigInteger in GWT since it doesn't strike me as an important use-case that you would instantiate a lot of them but never use them, but it might be worth looking at performance on IE8 to see if it can be improved (which might fix your problem in a more generally useful way). Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. You can also maintain a local fork of GWT if you think that is easier. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. Well, if you are sending lots of stuff to the client that isn't actually used on the client, that seems an obvious avenue for optimization. Again, just because you can easily ship it to the client doesn't mean you should. -- John A. Tamplin -- 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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
I agree; this seems like a workaround for one application that picked the wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? If someone wants to do some performance tests of GWT-RPC serialization, publishing the results would be useful to the community. My recommendation in this case would be create a new class named Id or Key that simply contains the BigDecimal, then modify the code to use it, then change the implementation to store the data in a string field instead. In the end you'll have more readable code. - Brian On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote: John, Well, if I don't have support for this patch then I better stop working on it. I can understand that this is not seen as a priority for GWT. Worst case I just replace the BigInteger/BigDecimal class in the project itself, that is basically what I did right now. Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. The Oracle JDBC drivers return a BigInteger if you force it to the extremes. Changing the application is not feasible, that will be too much work, we are talking about many thousands of dependencies in a huge codebase where BigIntegers and BigDecimals are used - while handling this optimisation on the RPC level can be done in just a few lines of code. In many cases we send large lists of objects that contain BigInteger, BigDecimals but only a few will actually be interacted with. So in that case we only need to convert the Strings to BigInteger (or BigDecimal) when really needed. David On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote: On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote: 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. I'm beginning to think such a change does not belong in GWT. In your example, wouldn't you be better served by only sending strings to the client rather than BigDecimals, if they client never does anything with them but send them back? I think it is going to be pretty rare in normal situations that you instantiate a BigDecimal but never actually use it in the client, so it seems the special-case hack for your use-case should be performed in your code instead. Too often people want to send things to the client that really don't belong there, and that includes particular representations of it. I know DTOs are extra work over just shipping your regular objects over the wire and GWT RPC makes that easy, but in many cases it is the wrong thing to do. Think about if you were building a proto for the communication -- would you send the data in the current form? If not, you shouldn't be sending it that way via RPC just because it is easy to do so. BTW, I thought Oracle sequence numbers did fit in long (aren't they int64?) -- at least all the JDBC code I see for manipulating them stores them in a Java long. -- John A. Tamplin -- http://groups.google.com/group/Google-Web-Toolkit-Contributors ---
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
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.
Re: [gwt-contrib] Issue 8083, needs some input from GWT team
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.
