This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: String hashCode
- To: tromey at redhat dot com
- Subject: Re: String hashCode
- From: Jeff Sturm <jeff dot sturm at commerceone dot com>
- Date: Thu, 01 Feb 2001 10:39:10 -0500
- CC: Bryce McKinlay <bryce at albatross dot co dot nz>, java at gcc dot gnu dot org
- Organization: Commerce One
- References: <3A789EDF.50A39A6C@albatross.co.nz> <87wvbbi44l.fsf@creche.redhat.com>
Tom Tromey wrote:
> The new data structure is an STL map<> (a red-black tree). I chose
> this because it has better worst-case performance than the existing
> hash table and is therefore better for real-time usage. The hash
> table is bad because rehashing makes the worst case expensive.
Some thoughts:
- Your performance scenario may not take cache behavior into consideration. A
binary tree can exhibit terrible spatial locality, causing several cache misses
or even TLB misses in the during lookups, because nodes may not be allocated
consecutively, or even close. That may end up more expensive than rehashing in
the worst case.
- It sounds as though you are targetting some sort of hard real-time with this
decision. Is this feasible at all, given the current state of our GC?
- What do you think about preserving both a hashtable and map implementation in
the source, so that one could be chosen at configure time?
--
Jeff Sturm
jeff.sturm@commerceone.com