I've not checked the code produced by the Gwt compiler, but I think it could introduce a bit of overhead or may be none (if the implementation code was 100% optimal). Anyway the use of String should guarantee that the final code is faster or equal.
-Manolo On Tue, Jul 13, 2010 at 11:02 AM, Andreas Karlsson <[email protected]> wrote: > Manolo, > > but if I understood you correctly you said there was a client side > performance penalty. If it's only in compile time I think it's easier > to let devs use stringbuilder in JS mode as well to be consistent. > > /Andreas > > On Tue, Jul 13, 2010 at 10:59 AM, Manuel Carrasco Moñino > <[email protected]> wrote: >> Yeah, Gwt should optimize them in compiler time, but at the end the >> optimization will produce arithmetic operations with javascript String >> implementation, and this optimization will penalize the time spent to >> compile. >> So why use StringBuffer instead of String unless this code was shared >> in both sides (js/jre). >> >> -Manolo >> >> On Tue, Jul 13, 2010 at 10:44 AM, Andreas Karlsson <[email protected]> wrote: >>> Is this really true? Shouldn't GWT optimize any overhead away and make >>> it similar to using String directly? >>> >>> /Andreas >>> >>> On Tue, Jul 13, 2010 at 10:41 AM, Manuel Carrasco Moñino >>> <[email protected]> wrote: >>>> I think the use of either will penalize the performance in client >>>> side, String should be faster. >>>> >>>> - Manolo >>>> >>>> >>>> >>>> On Tue, Jul 13, 2010 at 10:21 AM, guandalino <[email protected]> wrote: >>>>> Hi, GWT provides JRE emulation for both StringBuffer and >>>>> StringBuilder. The Java API says that in single threaded environments >>>>> the preferred choice is to use StringBuilder as it is faster. I also >>>>> remember to have read that browsers way to work is single threaded. >>>>> >>>>> So I'm wondering why and when one should use StringBuffer at all. Can >>>>> you clarify? >>>>> >>>>> Thank you. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Google Web Toolkit" group. >>>>> To post to this group, send email to [email protected]. >>>>> To unsubscribe from this group, send email to >>>>> [email protected]. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/google-web-toolkit?hl=en. >>>>> >>>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Google Web Toolkit" group. >>>> To post to this group, send email to [email protected]. >>>> To unsubscribe from this group, send email to >>>> [email protected]. >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-web-toolkit?hl=en. >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google Web Toolkit" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/google-web-toolkit?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google Web Toolkit" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-web-toolkit?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-web-toolkit?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
