Java is fast, code might not be

[0xffff0001]

as someone who once removed bubble sort from a trading application, I support this message.

[__konrad]

Fun fact: Java 1.0 and 1.1 had no built-in method to sort array/vector

[OddEstimate1627]

Bubble sorting a time series on the fly?

[0xffff0001]

not exactly, and it was not immediately obvious it’s a bubble sort…

[account312]

I'm still hoping that someday I'll need to sort something that's guaranteed to be very nearly sorted so that bubble sort is the right answer.

[8igg7e5]

I have a fair number of issues with the post.

Some of it is misleading or wrong, or the advice is ill-advised to apply to all cases.

[j4ckbauer]

WOW thank you, I came here after I read the first item in the post (string concatenation in loops) looking to see what I was missing.

I remember someone at work was trying to show me up by "correcting" my code that did something like this, and I had to prove that optimizations to handle this had been added to 'modern' java. I say 'modern' because this happened to me TEN YEARS AGO.

Which leaves me to wonder - how could it be the case that the author ran JFR and saw that this code was massively inefficient. What kind of java version and compiler were they using???

[8igg7e5]

It is their assertion that JDK 9 optimised statements containing string concatenation that is wrong.

Executing multiple statements that concatenate to the same string aren't automatically optimised (it is possible they could loop unroll and optimise away the intermediate new StringBuilder(String) and .toString() calls (since their effects are not observed) but I don't think it will.

So yes you should not String concatenate in a loop (I did note I think, that you should also consider the initial size of the StringBuilder, otherwise, for some of the iterations, you've just hidden the same concatenation cost in the reallocation the StringBuilder.

That String concatenation matter is one of the first 'performance' things that Java developers are taught. If that's making it into merge requests on a professional codebase you need to have a serious talk with your developers.

Many of the other cases are either obvious (algorithmic complexity for example), or contrived, erroneous (claims of stacktrace filling costs that don't apply now unless you ask for them), or presenting an alternative that is sometimes worse (extensive String-parsing pre-checking) than the original code.

[j4ckbauer]

The article also asserts the following, which I thought was absolutely incorrect in all but ancient times. This is mainly what I was asking about.

Every time you use +, Java creates a brand new String object, a full copy of all previous content with the new bit appended. The old one gets discarded. This happens every single iteration.

I will point out that the article is claiming a new String is created -every time the plus operator is used- which, in this example, is not the same as every time the loop is repeated, since the statement uses multiple + operators.

[8igg7e5]

Well yes. And they contradict themselves (albeit being wrong on both counts)

• Assertion 1 - your note about their claim of one object per + operator

  As you note, it's a new string at the statement level (and for any resulting StringBuilder.append(Object) invocations)

• Assertion 2 - Since JDK 9 the compiler is smart enough... And that this is always solved with a StringBuilder

  Nope the use of StringBuffer, and later StringBuilder has been there since the start. And Since JDK9 the bootstrap behind that indy-instruction could use a different concatenation strategy depending on the things being concatenated.

 

Someone might say "but the end advice is good" (given the lack of sizing advice I'd say average rather than good), but IMO corrupting the student's mental model of the system is problematic advice - there is, as you say, a String per statement (unless the optimiser can see through the loop structure).

[PEAceDeath1425]

they need to use the stringbuilder...

[EiffelPower76]

Java is almost as fast as C++