Some of the things are irrelevant because recent JVM can optimize them. I'm taking about StringBuffer and perhaps some stuff involving inlining of your code. However the 1000 repetition limit is not enough to experience that.
Especially things like #6. I'm sure the JVM would inline those calculations if the intermediate variables aren't used anywhere else.
The #6 is just an example.
I completely agree JVM optimizes in a lot of ways.
StringBuffer is way more efficient than normal String concatenation.
Benchmark Mode Cnt Score Error Units Benchmark.First.stringBuffer thrpt 25 52791,073 ± 196,355 ops/s Benchmark.First.stringConcat thrpt 25 7355,182 ± 39,284 ops/s
And this is on JDK 12.
For some reason your JDK decided out to replace str concat with stringbuilder. Look here for more information: dzone.com/articles/jdk-9jep-280-st...
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink.
Hide child comments as well
Confirm
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some of the things are irrelevant because recent JVM can optimize them. I'm taking about StringBuffer and perhaps some stuff involving inlining of your code. However the 1000 repetition limit is not enough to experience that.
Especially things like #6. I'm sure the JVM would inline those calculations if the intermediate variables aren't used anywhere else.
The #6 is just an example.
I completely agree JVM optimizes in a lot of ways.
StringBuffer is way more efficient than normal String concatenation.
And this is on JDK 12.
For some reason your JDK decided out to replace str concat with stringbuilder.
Look here for more information:
dzone.com/articles/jdk-9jep-280-st...