harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Blewitt" <alex.blew...@gmail.com>
Subject Re: Re: [optimization] Algorithmic tricks
Date Wed, 26 Jul 2006 20:00:04 GMT
On 26/07/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> Some hashCode functions are actually very *hot* methods (e.g. String)
> In this case I think that a bad but fast hashCode() could be better than
> good but slow. May be I'm wrong but only tests can show the difference.
> So if you have tests, I'm +1

Speaking of which ... I recall seeing an interesting behaviour back in
the Java 1.1 days when the hashCode() of a String used all the
characters when the String was less than a certain threshold (about
100 chars?) and then for larger sizes, took a stride of about every
tenth character. It was a real problem when I was doing a bunch of
hash inserts on long similar names that often only changed at the end;
so com.example.some.thing.here.ClassA and
com.example.some.thing.here.ClassB ended up having the same hash
because the stride was in effect and so didn't see the difference
between the two :-)

What effect would there be if we were communicating (via RMI) with an
implementation of a remote VM that isn't harmony? I.e.,if we have a
String "asdfasdfasdf" which hashes to (say) 8 on a Harmony VM, and a
remote implementation uses a hash of 12 for the same value, would that
cause any problems in an RMI layer? Do we care about such a scenario?


Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message