[Mono-dev] [U-SPAM] Re: String.GetHashCode()

Andreas Nahr ClassDevelopment at A-SoftTech.com
Sun Dec 2 17:32:27 EST 2007


Don't forget that 4 bytes per Hashcode isn't enough. You also need a boolean
to store if the hash is already computed (as e.g. 0 is a valid hash, too).
And then you would need one additional check for this boolean per call.
And don't forget that strings within the corelib ARE mutable to some extent.
 
Greetings
Andreas

  _____  

Von: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Alan
McGovern
Gesendet: Samstag, 1. Dezember 2007 17:22
An: Robert Jordan
Cc: mono-devel-list at lists.ximian.com
Betreff: [U-SPAM] Re: [Mono-dev] String.GetHashCode()


Also, just looking at the string source a bit more closely, it has a
GetCaseInsensitiveHashcode method too, so i'd assume that would need to be
cached too which would mean 8 bytes would be needed. This wouldn't scale
well. 

Fair enough. Twas just an idea.

Alan.


On Dec 1, 2007 4:09 PM, Robert Jordan <robertj at gmx.net> wrote:


Tinco Andringa wrote:
> (Woops, only replied to kamil)
>
> If Jerome is right and the overhead is only 4 bytes, then overhead
> shouldn't be a problem at all. The worst case size of a string would 
> be 1 character, of 2 bytes + something to end it with, like an int
> containing its length, 2 bytes, or a terminating character, probably
> 2 bytes too. Making it at least 4 bytes.  A worst case scenario of 


Look at a heavy string consumer: [g]mcs. The average string
length it has to process is probably only 4-5 chars long.
That's roundabout 12 bytes. Adding 4 bytes for the hash code
is a huge overhead that only pays out if GetHashCode is 
called frequently, but this is definitely not a common scenario
for most of the strings.

Robert


_______________________________________________ 
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
<http://lists.ximian.com/mailman/listinfo/mono-devel-list> 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071202/1cc1655f/attachment.html 


More information about the Mono-devel-list mailing list