Aleksey Shipilev — java.lang.String Catechism
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about String performance, such as whether to intern strings, how int-to-String conversion costs compare, and how G1 deduplication works.
Recommended by 5 people across 6 different months, 2015 to 2018.
What it is
A conference talk by JVM performance engineer Aleksey Shipilev, given at Joker 2014 in St. Petersburg, on how Java programs misuse java.lang.String. Framed around the seven deadly sins, it covers concatenation, substrings, interning, deduplication and hashCode, with benchmark-backed advice on cost and memory.
What people said
Recommends fge · 2015-03 · Stack Overflow · on “Java hashcode() collision for objects containing different but similar Strings”
Hmmm... Maybe you want to watch this video [this video] . Just a hunch but it may have the answer you are looking for (there is a section about `String`'s `.hashCode()` implementation)
Recommends Paul Boddington · 2015-10 · Stack Overflow · on “In Java, what is the difference between using the toString method vs explicit String casting vs plus quotes (ex. myObj+"")?”
This link [this video] (from 11:30) compares the difference in performance of the various ways to convert an `int` to a `String`.
Recommends apangin · 2017-01 · Stack Overflow · on “Java JDBC is not reusing String values?”
BTW, using `intern()` for deduplication is a bad idea. A simple `ConcurrentHashMap` is almost always a better choice. See this presentation [this video] for details.
Recommends apangin · 2017-11 · Stack Overflow · on “What is the performance impact of interning all strings in Java?”
Deduplicating common strings is usually a good idea to save memory. But never use String.intern for deduplication! String.intern is a native method; each call suffers from additional JNI overhead [LINK] . It blows internal hashtable which is shared among all JVM parts (e.g. class loading). The default capacity of string table is not large enough, and the number of buckets is constant. It may increase GC pauses since JVM scans this internal hashtable and possibly rehashes it during stop-the-world phase. More details in this presentation [this video] . A regular HashMap or ConcurrentHashMap can be a on order of magnitude better for this task. The following benchmark compares the performance of Stri
Recommends Basil Bourque · 2018-06 · Stack Overflow · on “Best way to optimize string data in an application that allocates quite a bit of it”
By the way, this talk may be of interest to readers: *java.lang.String Catechism* [this video] by Aleksey Shipilev [LINK] . Discussion of interning & deduplication & G1 starts at 29:00 [this video] .
Recommends esin88 · 2018-08 · Stack Overflow · on “String valueOf vs concatenation with empty string”
Even though answers here are correct in general, there's one point that is not mentioned. "" + intVar has better performance compared to String.valueOf() or Integer.toString() . So, if performance is critical, it's better to use empty string concatenation. See this talk [this video] by Aleksey Shipilëv. Or these slides [LINK] of the same talk (slide #24)
Cites Cargeh · 2017-04 · Stack Overflow · on “What is the need to override equals method in String class?”
String does override equals(), as seen in the extract from the source code below. Click here for source code. [LINK] However, it doesn't mean it uses this equals code all of the time. As you might know, Java starts out by interpreting the code from bytecode to machine code, and only after some time JIT compiles it into machine code. Now, at the stage of interpreting, the java.lang.String#equals method is used to compare strings. However, it's very slow . That's why, when JIT compiles the code, compiled code uses a different version of equals(), that is much faster (and not written in Java, I assume). Unfortunately, can't give you any details on this, so you'd have to dig into it yourself. Co
Cites Basil Bourque · 2017-10 · Stack Overflow · on “Is String Deduplication feature of the G1 garbage collector enabled by default?”
JEP 192: String Deduplication in G1 [LINK] implemented in Java 8 Update 20 added the new String deduplication feature: Reduce the Java heap live-data set by enhancing the G1 garbage collector so that duplicate instances of String are automatically and continuously deduplicated. The JEP page mentions that a command-line option UseStringDeduplication (bool) allows the dedup feature to be enabled or disabled. But the JEP page does not go so far as to indicate the default. ➠ Is the dedup feature ON or OFF by default in the G1 garbage collector bundled with Java 8 and with Java 9? ➠ Is there a “getter” method to verify the current setting at runtime? I do not know where to look for documentation