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 <[email protected]> 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 <[email protected]>wrote: > >> 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 <[email protected]> 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 <[email protected]> wrote: >>> >>>> On Thu, Jun 13, 2013 at 3:14 AM, David <[email protected]> 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 >>>> [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. > > > -- 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.
