Dismal performance of String.intern()

[Aleksey Shipilev]

Hi Steven,

On 08/05/2013 09:21 AM, Steven Schlansker wrote:
> Here is the patch I have at the moment:
> https://gist.github.com/stevenschlansker/6153643

Would you like to make char_cmp() and char_cpy() "inline"? In release,
they can then be compiled straight to memcmp/memcpy.

> This is almost a 3.5x improvement on fastdebug builds, and more than a
> 2.5x improvement on release builds.  It is now only ~50% slower than
> ConcurrentHashMap, at least for the low-contention case!  (I did not
> benchmark higher numbers of threads thoroughly, but I do not think that
> my changes could make that worse...)

The results look good. In fact, I think multi-threaded tests will show
how the StringTable works under contention, and whether the changes you
made are making it worse or better is the open question. (I bet for
"better").

> Finally, the benchmark code:
> https://github.com/stevenschlansker/jvm-intern-benchmark/blob/master/src/main/java/org/sugis/benchmark/InternBenchmark.java
> 
> It is not the best ever benchmark, but I'm hopeful that it's "good
> enough" to demonstrate the wins I have.  Please let me know if you
> believe the benchmark invalidates my conclusions.  It is run with JMH,
> as that seems to be the standard way of doing things around here.

The benchmark is good, actually. You pay for the cost of constructing
the interner, though, but it seems to be the lesser of two evils (i.e.
cleaning the interner is more of the hassle). A few minor nits:

 a) It seems better to design this benchmark this way: prepare the list
of random Strings (Ioi's suggestion to juggle the string lenghts fits
nicely there), feed them to interner, return the interner from the @GMB
method. You will save a lot of blatant allocations like "new
String(buf)" in the hot loop, as well as make loop more unpredictable
(e.g. not relying on successful hoisting).

 b) @BenchmarkMode can float up to class level. Less scaffolding.


-Aleksey.