alan.mcgovern at gmail.com
Sat Dec 1 11:21:52 EST 2007
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