Re: Fwd: Re: [Libreoffice-commits] core.git: Move string hash function into String class.

On 02/14/2014 06:39 PM, Stephan Bergmann wrote:
> O(1) sampling was apparently considered state of the art when the rtl 
> string classes were first created, closely copying java.lang.String, 
> which at that time demanded sampling for hashCode(), too---but never 
> sampling more than 15 characters, with the obvious (in hindsight, at 
> least) performance catastrophes, so they changed it to O(n) somewhere 
> along the way.
>
> Based on that, I wouldn't mind changing the rtl string classes' 
> hashCode behavior, too.  However, what I very much want to avoid is to 
> needlessly enlarge the URE stable interface---i.e., I think we should 
> stay with a single, general-purpose hashCode function per class.
If we can have the hashCode do the hash on the entire string - I would 
prefer that too.
> Also, given the usage in SdPage::getHash (sd/source/core/sdpage2.cxx), 
> I see that the input strings are potentially long and too similar to 
> each other for sampling to work well.  However, wouldn't it be better 
> anyway to get rid of the stringify function there that builds up a 
> long string only to have it reduced to a hash value?
How else would we build a hash value without too much work? I have added 
a hash for SfxItemSet as well recently. (Next step would be to reuse 
that hash in SdPage, of course).

Thanks!
Muthu Subramanian
> Stephan