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.
