Dismal performance of String.intern() (original) (raw)

Andrew Haley aph at redhat.com
Mon Jun 10 22:55:42 UTC 2013

On 06/10/2013 07:06 PM, Steven Schlansker wrote:

I discovered that replacing String.intern() with a ConcurrentHashMap improved performance by almost an order of magnitude. I'm not the only person that discovered this and was surprised: http://stackoverflow.com/questions/10624232/performance-penalty-of-string-intern I've been excited about starting to contribute to OpenJDK, so I am thinking that this might be a fun project for me to take on and then contribute back. But I figured I should check in on the list before spending a lot of time tracking this down. I have a couple of preparatory questions: * Has this bottleneck been examined thoroughly before? Am I wishing too hard for performance here? * String.intern() is a native method currently. My understanding is that there is a nontrivial penalty to invoking native methods (at least via JNI, not sure if this is also true for "built ins"?).

That's not really true. For simple JNI methods I've measured the overhead in nanoseconds.

I assume the reason that this is native is so the Java intern is the same as C++-invoked interns from within the JVM itself. Is this an actual requirement, or could String.intern be replaced with Java code?

I don't think that replacing intern() with Java code is a great place to begin. Surely your first plan should be to improve the performance of the C++ version. Maybe the only problem is that it needs a better hash table. Rather than get into complex re-engineering of VM startup, this might be an easy fix.

Andrew.

More information about the core-libs-dev mailing list