[Mono-dev] [U-SPAM] Re: String.GetHashCode()
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.
Von: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Alan
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
Fair enough. Twas just an idea.
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.
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list