[Mono-devel-list] [IDEA] Caching String Hashcodes

[Ben Maurer]

On Sat, 2004-05-01 at 09:40, Andreas Nahr wrote:
> Hi,
>  
> I thought about a pretty simple thing. As strings are immutable we are
> able to cache their hashcodes. For (long) strings that make several
> calls to GetHashCode this would give us an incredible perf boost.
> However it will cost us 4 bytes of additional data per string even if
> the hashcode isn't used at all.

I doubt it. Feel free to try, but I really doubt you are going to notice
it in a good benchmark.

You might see a huge boost for a large string, but i would only be
impressed if you were able to show a metric such as MCS bootstrap time
reduced by 3%.

One trick that might possibly make sense it to use the SyncBlock field
as a place to somehow store the hashcode (so, you could allocate a
syncblock if ghc is called, and store the result in there. if the block
exists, check for a hashcode). This would avoid four bytes of wasted
memory for everyone. However, this might prevent us from doing it in
managed, which would be a very bad thing. Also, It would still take some
sort of benchmark to convince me this is worthwhile.

Also, part of the overhead may be the icall. I am working on getting the
JIT so that we can implement this in managed code (we just need a few
more optimizations).

I gave you a list before of optimizations that would be truly helpful.
Also, last night I checked in some benchmarks that the JIT could do
better on. They are things that show up in real code. You might want to
try them.

-- Ben