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