Ok, I found the problem. It's with our perftests and unfortunately it means that numbers are going to get slightly worse across the board.
In the tests we are using the same ObjectName instance for registration and invokes. This means that when we lookup the objectname in the registry the string.equals() methods are benefitting from a shortcut in String which returns true if strings are *reference* equivalent (which they are).
Whew. At least I understand what's happening now.
Each of these is 10,000,000 invocations
averaged over 3 tests
It looks like it always calculates the hashCode
for "" and caches everything else.
Where are we using "".hashCode() ?
I don't see it :-(
Crossed in the post :-)
What numbers do you get RI/JBoss?
Caching ObjectName instances is a valid optmization,
but we need to test both.
WRT the "" hashcode calculation always happening - that's because String.hashCode() caches the hash as an int and only calculates it if it's 0. For "" it's always 0 so it always calculates.
As for caching ObjectNames - the only way to guarantee fast lookups on a cached objectname is if you cached the one stored in the registry. The only way to get that one is by querying the MBeanServer for the ObjectInstance.
It's a valid optimisation and it will save time but only about a second per *million* invokes on my machine.
I think the rest of JBoss will only notice that for a million invokes the RI takes about 70 seconds while we will take something like 5 or 6 seconds.
I think in JDK1.4 the comparison will be about 25 seconds for the RI and about 3 seconds for us.