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

On 02/14/2014 11:01 AM, Muthu Subramanian wrote:
> a) Not sure what other things depend on hashCode - I assumed the
> functions which call that
>       are ok with sampling based hash and needs it quick?
> b) argh :( I added the rtl parts, I guess I missed the helper part -
> will do.
> c) Oops will change that
> d) Will add this as well
> e) this one as well.
>
> I will do the changes depending on (a) - what would you prefer, please?
> Should I just fix hashCode()?
> There is specific code there to do the sampling - I thought that was
> intended?
> If you ask me, I would prefer to do it separately - like I have done it
> now.

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.

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?

Stephan