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 >
_______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list