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