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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Alan McGovern Gesendet: Samstag, 1. Dezember 2007 17:22 An: Robert Jordan Cc: mono-devel-list@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 <[EMAIL PROTECTED]> 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@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list <http://lists.ximian.com/mailman/listinfo/mono-devel-list>
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
