This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: String hashCode
- To: Jeff Sturm <jeff dot sturm at commerceone dot com>
- Subject: Re: String hashCode
- From: Tom Tromey <tromey at redhat dot com>
- Date: 02 Feb 2001 15:38:20 -0700
- Cc: Bryce McKinlay <bryce at albatross dot co dot nz>, java at gcc dot gnu dot org
- References: <3A789EDF.50A39A6C@albatross.co.nz> <87wvbbi44l.fsf@creche.redhat.com> <3A79831E.29E0E528@commerceone.com>
- Reply-To: tromey at redhat dot com
>>>>> "Jeff" == Jeff Sturm <jeff.sturm@commerceone.com> writes:
Jeff> - Your performance scenario may not take cache behavior into
Jeff> consideration. A binary tree can exhibit terrible spatial
Jeff> locality, causing several cache misses or even TLB misses in the
Jeff> during lookups, because nodes may not be allocated
Jeff> consecutively, or even close. That may end up more expensive
Jeff> than rehashing in the worst case.
Interesting, thanks.
Jeff> - What do you think about preserving both a hashtable and map
Jeff> implementation in the source, so that one could be chosen at
Jeff> configure time?
I'm cool with that. I'm not even convinced I should check in my
current implementation, given the number of comments I've seen. Our
customer needed it, but I can continue to maintain the change as a
divergence if need be.
I think using a hashtable is as simple as changing a typedef to use
`hash_map' instead of `map'.
Tom