string hash performance

Mon Aug 12 15:44:00 GMT 2002

On Wed, 7 Aug 2002, Eric Blake wrote:
> In response to Hans answer, String.hashCode does not use
> Object.hashCode, so the location of a String object in memory has no
> effect on whether hashing would be useful. Thus, if gcj does merge with
> classpath, all String objects would become at least 4 bytes larger to
> store the cache. Tom, that may be something for you to consider when
> you ever do get around to looking at my patch.

I did some benchmarking with the cachedHashCode bits of your patch.
Interestingly, it helped considerably on my interpreter benchmarks,
chopping about 15% off total run time.
I also tried some other common techniques. All runs with -O2
-fno-bounds-check -fno-store-check, additional switches as indicated:
i686-pc-linux-gnu
millis
------
 1070
 863 static
 731 static + hashcode
 612 static + hashcode + ms8m
 653 static + hashcode + ms8m + inline[1]
 603 static + hashcode + ms8m + inline[2]
static = linked with libgcj.a
hashcode = libgcj rebuilt with Eric's cachedHashCode patch
ms8m = initial heap set to 8MB (via GC_INITIAL_HEAP_SIZE)
inline[1] = app built with Andrew's inliner patch and -finline-functions
inline[2] = additional tweaks over inline[1], e.g. max-inline-insns=100
In comparison:
millis
------
 673 HotSpot 1.4 -client
 540 HotSpot 1.4 -server
 549 IBM JDK 1.3.0
 110 tclsh 8.3
(the last is from the C-based interpreter, of course. Whoever said Java
could be faster than C?)
There is still quit a bit of improvement possible here though I'm not sure
where it will come from. I had trouble getting any real improvement from
the inliner, but it is still experimental code.
Jeff