HybridDictionary

  • Thread starter Thread starter William Stacey [MVP]
  • Start date Start date
W

William Stacey [MVP]

I take it the reason HybridDictionary may be faster then a normal Hashtable
with 10 items is less is the cost of generating hashcodes ? Other reasons?
 
William,

I think that this is part of it, but depending on the object, that might
not always be the case. For example, if you were doing case-sensitive
comparisons of strings, then I would assume that the hash code for the
string would be very quick, since it is generated once (due to the fact that
strings are immutable). Calling GetHashCode over and over again would be
quick.

Also, cycling through 10 items and doing a comparison is probably much
quicker than generating hashcodes for everything (remember, a hashcode has
to be generated on lookup, as well as insertion and deletion). This is
probably where you see the speed the most.

Hope this helps.
 
Yes there was a tuning metric done and it was found to be faster in certain
cases than allowing the generation of the hash code. Hash codes for strings
take time compared to the length of the string, so for something like a keyed
dictionary (aka ViewState and Session in ASP .NET), it was faster to
enumerate the collection than to hash index it.

Note for non-string keys you are probably better off using a Hashtable, since
hashing of integers is much faster (return the integer) than hashing a string
(computation).

Was there a size issue as well? Possibly, since thousands and thousands of
nearly empty or completely empty Hashtable or ListDictionary actually consume
memory. The HybridDictionary is late init, so that if you construct it normally
without an initial size, it will actually consume very little memory since it
won't
allocate storage.
 
Hey now, can't go spitting out possibly bad information like the hash code
is only calculated once. The rotor implementation at least has no storage
for the computation of a strings hash code, and so using the same string
over and over again will result in the hash being computed multiple times.


--
Justin Rogers
DigiTec Web Consultants, LLC.
Blog: http://weblogs.asp.net/justin_rogers

Nicholas Paldino said:
William,

I think that this is part of it, but depending on the object, that might
not always be the case. For example, if you were doing case-sensitive
comparisons of strings, then I would assume that the hash code for the
string would be very quick, since it is generated once (due to the fact that
strings are immutable). Calling GetHashCode over and over again would be
quick.

Also, cycling through 10 items and doing a comparison is probably much
quicker than generating hashcodes for everything (remember, a hashcode has
to be generated on lookup, as well as insertion and deletion). This is
probably where you see the speed the most.

Hope this helps.
Click to expand...
 
Back
Top