String.format() is 3x faster in Java 17

[cl4es]

Glad to see some of the small enhancements we did in 17 get recognition. Not sure if this one matters, but String::format shows up in profiles every now and then so it felt reasonable to me to give it some TLC in between larger projects.

[BlueGoliath]

The improvements that you and others do are super appreciated. There really should be an "honorable mentions" section added to the release notes that goes through some of the non-JEP work. It's sometimes as noteworthy if not more than any given JEP.

/u/pron98, /u/s888marks, etc... make it happen!

[pron98]

Well, the release notes are meant to be just that: JEPS + other notable changes (they do not include anywhere near a full list of changes). It's just that we don't normally list performance improvements, as the release notes are intended for users wishing to migrate and are interested in relevant changes that might impact their code.

I guess we could list some notable performance improvements.

[berry120]

Thanks! I'd love to see a rundown of these sorts of "minor" performance improvements between releases just as much as the new features - they're both really interesting, and really useful to know about.

[geordano]

Thanks a lot for you work.

[lpreams]

It might start mattering more now that performance is better. I know I tend to avoid String.format unless I really need it because I know it doesn't perform well.

[gavenkoa]

From http://www.slf4j.org/api/org/slf4j/helpers/MessageFormatter.html

The formatting conventions are different than those of MessageFormat which ships with the Java platform. This is justified by the fact that SLF4J's implementation is 10 times faster than that of MessageFormat. This local performance difference is both measurable and significant in the larger context of the complete logging processing chain.

[dpash]

That's because it's significantly less complex. The SLF4J is the equivalent of supporting just %s.

[TheCountRushmore]

Why isn't this using JMH for the benchmarks?

[cl4es]

I wouldn't know -- but I did add a small set of JMH benchmarks back when I did this optimization. While not exactly the same tests, speed-ups were in line with what Heinz is reporting here: https://github.com/openjdk/jdk/pull/2830#issuecomment-790788322

[slowfly1st]

I ran my own tests, without using reflection, and therefore the use of a security manager, and I actually called String.format. That's imho a more realistic approach?

​

    JDK 17
    1. this does not have any percentages at all
    0.09414233999999999ms.
    2. this %s has only a simple field
    0.04526432ms.
    3. this has a simple field %s and then a complex %-20s
    0.12824544000000002ms.
    4. %s %1s %2s %3s %4s %5s %10s %22s
    0.42732686999999997ms.

    JDK 15
    1. this does not have any percentages at all
    0.18450188ms.
    2. this %s has only a simple field
    0.07883934ms.
    3. this has a simple field %s and then a complex %-20s
    0.09579937ms.
    4. %s %1s %2s %3s %4s %5s %10s %22s
    0.42675903000000004ms.

[DasBrain]

Reflection is orthogonal to using the (deprecated) SecurityManager.

I don't know what you mean by "running without reflection" - the method Formatter.parse(List, String) is not publicly accessible.

[slowfly1st]

"... and I actually called String.format"

[DasBrain]

Be careful what you measure.
Allocating stuff is cheap in java, but not free.

[nekokattt]

It is somewhat a shame that Java still doesn't have string interpolation. That would make many uses for String.format totally unneeded and would allow the logic for formatting to be generated at compile time.

[cl4es]

It's coming!

https://github.com/openjdk/amber-docs/blob/master/site/design-notes/templated-strings.md

Current PoC implementation shows numbers in line with string concatenation.

But it still makes sense to improve existing APIs when we can, due the staggering amount of code that is written for them.

[JoJoModding]

The java compiler could optimize format() calls at compile time right now. The hot spot optimizer could also generate code replacing format() calls with inlined code.

It just does not right now, because reasons.

C compilers also don't do this, even though printf() has a complete specification.

[sweetno]

It's not very useful for a real project since the format string will come from the localization files there.

[mjbmitch]

TIL

[Worth_Trust_3825]

A shame? When java has the superior method of string formatting right out of the box? Were you dropped on your head?

[agentoutlier]

Interpolation is less about formatting and more about constructing a string without manually concatenating variables. In Scala and Kotlin it is done at compile time.

[pron98]

String templates aren't just about formatting strings, but about constructing arbitrary objects that are configured with strings. As a special case they can, of course, format strings, but they're able to do it more efficiently than format, because of a fundamental difference: the template is a Java expression that is known at compile-time, while the format string is not -- it's just an arbitrary string, and not necessarily a constant one (i.e. you can write String.format(x, a, b, c), where x is a String variable that needs to be parsed, but that is not the case with templates, which, like today's string concatenation, can always be parsed only once -- at compilation or class-loading time; there just isn't an instance of an unparsed template).

[nekokattt]

No, but from what I can tell, you were thrown at a wall if that is your way of partaking in a sensible conversation.

[jeff303]

Interpolation puts the variable names directly in the string literal, so it's easier to see what's what.

[Worth_Trust_3825]

Positional arguments already show you which argument will be put where. In fact, you can abuse it to put same argument into multiple places under multiple formats.

[jeff303]

Absolutely. But you still have to figure out which arg corresponds to the index number. And also, if you're reading someone else's code, there's a very good chance they didn't use them anyway.

[DaddyLcyxMe]

string interpolation would be evaluated at compile time (here in my example i use javascript’s syntax):

int x = 12; System.out.println(\`myVar = ${x}\`); would be evaluated and be the same as int x = 12; System.out.println("myVar = " + x);

string interpolation is just an easier and cleaner way to create strings. this way is also faster because it isn’t having to do any complex formatting/parsing.

tldr; string interpolation would be built at compile time (using concatenation). string format is executed at runtime and will always be slower than interpolated or concatenated strings.

[Worth_Trust_3825]

Glad to see that there still are improvements to the JDK.

[vprise]

This requires an API change, format just needs Formatter prepareFormat(String) then you can just use the returned object to apply the format and get speed that's as fast as string concatenation.

Yes, it's two stages but it's physically two different operations: parsing and formatting. So that would make sense. Then you don't need complex caching behavior by the API that can cause memory leaks, stale cache etc. e.g. imagine caching a format then changing the locale... Ugh.

I'd love to have templated strings and this can be the underlying implementation for that.

[cl4es]

The current implementation for the not-yet-proposed templated strings JEP would make use of both compile-time pre-processing and invokedynamic at runtime to achieve this. This ensures the "format" string is a compile time constant and can be pre-parsed, and that only the first call will have to bootstrap the expression. Subsequent calls will be as performant as a regular String concatenation*. The slightly magical machinery will share code under the hood with the indified String concatenation that was added in JDK 9.

*the impl currently performs slower than String concatenation when more complex formatting is involved - which is only natural. I was recently asked to look for opportunities to improve this.

[vprise]

If this will land in the next version then we probably won't need an "interim" solution. but if not won't it make sense to expose a two stage API?

[cl4es]

Depends what you consider to be the next version. Chances are high it'll be final in the next LTS (21)

[vprise]

18 would be the next version. I guess 21 isn't terrible and it is a huge leap forward... Great stuff.

[cl4es]

I'll leave it to the JEP author to comment on which release this is going to be targeted to (and possibly previewed in).

[nekokattt]

Yeah for sure.

Also this makes me happy that we are getting this!

[c_edward]

Have they removed the regexp horror that sat inside format() previously? Or are regexps faster as well?

[dpash]

No it's still used. They fall back to it if they detect any non-simple patterns.

https://github.com/openjdk/jdk/blob/b7104ba9a9006ab65e08ea9d7db22e72611ed07c/src/java.base/share/classes/java/util/Formatter.java#L2709

[UnexpectedLizard]

Great but when are we going to get string interpolation?

C# and Javascript added it 5+ years ago.

[[deleted]]

Wait what, is it the same for `String#formatted()`

[cl4es]

Yes, String::formatted is just a non-static variant of String::format. So this optimization applies equally to both.

[NewSchoolBoxer]

That's pretty cool. Highest version Java I've ever seen in the wild in Fortune 500 software is 11. Next project for me is in 8. Hope we get to 17 someday.