StringBuffer vs StringBuilder in GWT
guandalino
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.
Paul Robinson
for java environments, although typically they are short-lived objects
that are used on only a single thread. If you only use it on a single
thread, you may as well use StringBuilder which is faster because its
methods are not synchronized. So you should only use StringBuffer if you
want to read/write the contents across multiple threads.
For GWT client code, the general rule is that the synchronized keyword
is ignored because it's single threaded. In the case of StringBuffer and
StringBuilder, they are both emulated and the source code for their
client-side versions is identical apart from the name. So for GWT, it
makes no difference which you use.
StringBuilder was only introduced in Java 1.5, so there's a lot of older
code and examples that use StringBuffer that could/should use
StringBuilder.
Paul
Manuel Carrasco Moñino
side, String should be faster.
- Manolo
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
>
>
Andreas Karlsson
it similar to using String directly?
/Andreas
Thomas Broyer
StringBufferImpl implementation, so it really doesn't matter which one
you use.
StringBuffer is emulated because StringBuilder didn't exist in Java
1.4, and GWT started to support Java 5 only two years ago in GWT 1.5.
I think you should now stick to using only one of them, and my
preference goes to StringBuilder (if it really is faster, then it
should improve performance in DevMode)
Nabeel Ali Memon
guandalino
[cut]
> makes no difference which you use.
added to existing documentation.
Manuel Carrasco Moñino
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
Andreas Karlsson
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
Manuel Carrasco Moñino
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
Thomas Broyer
On 13 juil, 11:10, Manuel Carrasco Moñino <man...@apache.org> wrote:
> 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.
which case you'll suffer a very small, and negligible, penalty at
runtime) or array-append-then-join, depending on which method was
benchmarked the fastest in each browser.
http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/super/com/google/gwt/emul/EmulationWithUserAgent.gwt.xml
The GWT has experimented with many options before settling on these
two: using a.push() or a[arrayLength++] to append to an array, using
join() or String.prototype.concat.apply() to join the array items into
a string, etc. you'll find them all in the subversion repository:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/src/com/google/gwt/core/client/impl/
Note that string concatenation is done using the += operator, which is
more performant than s = s + something in some browsers (AFAIK).
So really, GWT is optimized here, and you shouldn't fear from using
StringBuilder (or StringBuffer) if you think they're necessary (of
course, when concatenating 3 strings, it might not be worth it;
StringBuilder is mostly useful with loops and/or building large
strings, and this is true in both Java and GWT)
Manuel Carrasco Moñino
Both StringBuilder and StringBuffer generates the same javascript code.
I have coded a simple test (see below) to check append and these are
my results (Compiled code):
- all browsers except IE performs identical using String, StringB.
- IE6 performs better using StringB.
- IE8 performs better using normal String.
In hosted mode, the performance is better for StringB
Cheers
-Manolo
public void testStringOperations() {
int TIME = 20000;
String DATA = "sadfasdf";
String s = "";
double ss = new Date().getTime();
for (int i=0; i<TIME; i++) {
s += DATA;
}
double se = new Date().getTime();
String a = "";
double as = new Date().getTime();
for (int i=0; i<TIME; i++) {
a = a + DATA;
}
double ae = new Date().getTime();
double bs = new Date().getTime();
StringBuffer b = new StringBuffer();
for (int i=0; i<TIME; i++) {
b.append(DATA);
}
double be = new Date().getTime();
double us = new Date().getTime();
StringBuilder u = new StringBuilder();
for (int i=0; i<TIME; i++) {
u.append(DATA);
}
double ue = new Date().getTime();
RootPanel.get().add(new Label(se - ss + " " + s.length() + " String += "));
RootPanel.get().add(new Label(ae - as + " " + a.length() + "
String = String + "));
RootPanel.get().add(new Label(be - bs + " " + b.length() + "
StringBuffer" ));
RootPanel.get().add(new Label(ue - us + " " + u.length() + "
StringBuilder" ));
}