4 ms·
Here is the patch (I believe): http://hg.openjdk.java.net/jdk8/tl-gate/jdk/rev/2c773daa825d http://hg.openjdk.java.net/jdk8/tl-gate/jdk/rev/2c773daa825d I was
by justinsb 13y ago
Here is the patch (I believe):
http://hg.openjdk.java.net/jdk8/tl-gate/jdk/rev/2c773daa825d http://hg.openjdk.java.net/jdk8/tl-gate/jdk/rev/2c773daa825d
I was quite surprised that we _always_ copy the array. I would have guessed that .substring(1) (all but the first character) is very common, and that it would be a win to share the array in some circumstances. A straw-man heuristic would be "share the array if we're using at least half of it".
But they didn't do that. Anyone know if there's a public discussion?
- swinejihad 13y agoThe way I see it the big win for memory is the fact that they've shaved off two ints from every String instance. Most Strings are small and probably never have .substring called on them, so I think memory use might even be lighter by always copying but using a smaller String instance in most typical cases.
- hnriot 13y agoDoes it matter with copy-on-write?
- dietrichepp 13y agoWhat? Java's strings are immutable, so copy-on-write is nonsense. Performance tuning for mutable string types has been moving away from the copy-on-write paradigm (it used to be common in C++, but not any more). It's a big mess because the design of the C++ string class was truly botched, it's much less of a mess in other languages where you have different types for mutable and immutable strings (Java, C#, Python, etc.)