Dismal performance of String.intern()
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:
> 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
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.
More information about the core-libs-dev