This is the correct implementation of the idea developped in Lucas De Marchi's blog :
http://www.politreco.com/2013/09/optimizing-hash-table-with-kmod-as-testbed/
This give an interesting +15% for all Eina_Hash user whatever hash function they use. The inlined
djb2 is still the fastest one and all other give very close result. It does increase memory foot
print, but as much as the previous way of doing it.
This give an interesting +15% for all Eina_Hash user whatever hash function they use. The inlined
djb2 is still the fastest one and all other give very close result.
This idea was given by Lucas De Marchi's blog :
http://www.politreco.com/2013/09/optimizing-hash-table-with-kmod-as-testbed/
I do believe that rolling a crc32 implementation as a hash function should give interesting result
in our test.
We did use this 'begin' boolean to make eina_hash always allocate only
once per item it push in the hash. This boolean was alone at the end of
a structure. It would have costed us 4bytes on 32bits system and 8bytes
on 64bits. Removing it make elemines consume 100KB less on 32bits system.
We may have a speed impact on hash insertion here, but I don't think we
do use eina_hash_add and friends in any hot path, at the moment. If that
was the case there would be some way to mitigate this, just not worth it
at the moment.
Thanks goes to Thiago Macieira for sharing the issue. This
is the result of the cross-desktop talk at fosdem. A lot more
comming in the futur !
SVN revision: 83578
Cedric Bail
Cedric Bail
Carsten Haitzler
Lucas De Marchi
Vincent Torri