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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
