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.
