A fast mostly collision free hash ?
Jean-Marc Lasgouttes
lasgouttes at lyx.org
Wed Nov 9 11:29:49 UTC 2022
Le 08/11/2022 à 20:44, Pavel Sanda a écrit :
> I do not follow what's your problem with QHash? Hash tables are designed too have
> collisions from time to time.
My problem here is that I have a cache
[string, screen width] -> [points where to break the string]
In the example file submitted by Scott in #12598, the string is 500kB
long, and therefore, this will need to be stored in the cache.
In general, I will need to store in the cache an amount of data ~equal
to the document size, and I think it is not really necessary.
This is why I am looking for a fast and almost-collision-free hash to
store in the key.
Is it clearer now ?
JMarc
More information about the lyx-devel
mailing list