[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 23 April 2014 14:14, Evan Huus <eapache@xxxxxxxxx> wrote:

On Wed, Apr 23, 2014 at 9:11 AM, Anders Broman
<anders.broman@xxxxxxxxxxxx> wrote:
>     >In my benchmarks it is measurably slower than GHashTable, but not
> excessively
>
>     >so. Given the additional security it provides this seems like a
> reasonable
>
>     >trade-off (and it is still faster than a wmem_tree).
>
>
>
> Any idea what makes I slower? The hash algorithm?
> http://www.azillionmonkeys.com/qed/hash.html

Effectively. It has to do a fair bit more work per hash in order to
properly mix in the randomness and prevent algorithmic complexity
attacks.

The implementation is simpler, so there are probably other areas where
glib is slightly more optimized, but I expect the stronger hash is
most of it.

Looks to have broken the Win x64 build:

wmem_map.c(223) : error C2220: warning treated as error - no 'object' file generated

wmem_map.c(223) : warning C4267: 'initializing' : conversion from 'size_t' to 'guint32', possible loss of data