Dismal performance of String.intern()
stevenschlansker at gmail.com
Mon Jun 10 23:01:28 UTC 2013
On Jun 10, 2013, at 3:55 PM, Andrew Haley <aph at redhat.com> wrote:
> 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.
Sorry to double-reply, but I thought it worthwhile to note that the time to intern strings via ConcurrentHashMap is measured in the low double-digit nanoseconds on my machine, so this may indeed end up being nontrivial. But I will consider it trivial unless I can measure it to be large.
>> 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