Stefan Israelsson Tampe <stefan.ita...@gmail.com> writes: > After optimising the hashtable implementation I conclude the following, > 1. + 0.25s 10M lookups in small hashtable (0.36s for guiles current) > 2. + 6X faster for a large table scanning numbers
What do you mean by "large taable scanning numbers"? (I don’t understand) > 3. + The general hash interface is faster also because it does not call SCM > from C > 4. + fast (2X) for relative large random working sets although the hashtable > is large That would likely directly speed up code I have by factor 2. > 5. - we do not suport the assoc generalisation (sort off though) What do you mean by assoc generalization? > 6. Compact (low memory overhead) All in all these improvements sound great! And low memory overhead is the icing on the cake. How big is the remaining overhead? (compared to storing the values in a vector?) > Let me know if you want to have this supported in guile as I have defined > some vm operations that are needed else this will be about 1.5 2x slower on > small hashtables. Since I do not know the implications of this on the VM, I cannot give an answer. If Andy Wingo doesn’t object, then I think these improvements would be awesome to have! Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature
