On Wednesday 26 July 2006 13:03, Anton Luht wrote:
> Hello,
>
> One of possible candidates for such optimization may be for example
> String.hashCode() . Current implementation is rather common. Wikipedia
> points to hash functions that look more advanced (
> http://en.wikipedia.org/wiki/Hash_function ).
Seems to me that String.hashCode() has to use the algorithm described in the
spec if it's to be compliant. An application which relied on known values of
hashCode() might be stupid, but it would be according to contract.
switch(opcode.hashCode()) {
case NOP_HASH_CODE: do_nop();
case ALOAD0_HASH_CODE: do_aload0();
...
}
You could consider using a better hashcode for e.g. string interning (private
ind internalHashCode() {...}); if your internal hashcode is both faster and
better than the "official" one then that's a clear win. But as has been
pointed out elsewhere in this thread, in general it's a trade-off between the
effort required to calculate the hashcode and the collision rate in the
hashtable. No point in having a world-beating hash function for a table which
is s small that linear search would be fast enough ...
Chris
--
Chris Gray /k/ Embedded Java Solutions BE0503765045
Embedded & Mobile Java, OSGi http://www.k-embedded-java.com/
[EMAIL PROTECTED] +32 3 216 0369
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
