Op Fri, 04 Apr 2008 23:19:34 +0200 schreef Roedy Green =
<see_website@[EMAIL PROTECTED]
>:
> I'm curious just how clever HotSpot is about optimising StringBuilder,=
Why? If string manipulation is your main bottleneck, then probably it's=
=
better not to use StringBuilder. Or to do less string manipulation. Or=
=
both.
> Here are some possible optimisations.
>
> 1. when allocating the StringBuilder, compute the length where
> possible to create the exact size.
This will cost performance if the programmer already chose an acceptable=
=
guesstimate.
> 2. when doing append ( "xxx");
> append ("yyy");
> convert that to append( "xxxyyy");
I don't consider this an optimisation, as it will cost memory (and =
performance if the code isn't used enough) at the expense of tasks which=
=
could very well be much more im****tant than string manipulation.
> 3. when doing toString, if char[] internally is the correct length,
> steal that array to use in the string, and lazily make a copy (which
> should be rarely needed.)
Interesting. Also, it should be possible to determine the usage of the =
=
char[], and so to not keep a reference around when it isn't needed.
> 4. convert append ( " " ) to append ( ' ' );
The source compiler should have done this. Otherwise, if the referenced=
=
string is a variable (which varies in length), it is probably not feasib=
le =
(because something will need to check the length anyway).
> 5 convert append ( a + b + c ) to append (a ); append (b); append
> (c);
Should have been done by the source compiler. Even if you have code lik=
e =
this:
StringBuffer buf =3D new StringBuffer();
buf.append(a).append(b).append(c);
builder.append(buf);
> If it is not clever, then consider how you might implement these with
> a BYTE CODE optimiser.
-- =
Gemaakt met Opera's revolutionaire e-mailprogramma: =
http://www.opera.com/mail/
|
