Re: StringBuffer/StringBuilder efficiency
On Sep 24, 2:10 pm, markspace <nos...@nowhere.com> wrote:
Wojtek wrote:
So it does not use the existing StringBuilder and just create.append()
calls? So if I have several of the concatenation lines I will have
several temporary StringBuilders created?
Yuck
I thought I'd also point out, that this is only "yuck" if the code in
question is part of the 20% of your application that gets executed
frequently. A few extra StringBuilder objects here and there won't hur=
t
anything. While making some "obvious" early optimization is ok, don't
feel the need to remove every single extra StringBuilder.
Just write code that you think looks correct, then profile it. When th=
e
profiler finds sections that are executed frequently, then optimize the
bleep out of those parts. Don't waste time optimizing code that won't
be executed but occasionally.
Furthermore, the optimization of today could be the performance drag
of tomorrow. In principle HotSpot could dynamically perform many of
the optimizations we're discussing doing by hand. Maybe it does that
today, maybe it doesn't, but also maybe it will in the next release.
Naturally you cannot determine this by looking at the bytecode. You
might find yourself hand-optimizing something HotSpot would have done
for you, or will have done for you.
All the more reason to follow markspace's advice, with the addendum
that you should profile under JVM options similar to what you expect
in production with similar data input, accounting for HotSpot warmup.
(And with the same brand of JVM.)
--
Lew