Re: Hash map implementation for wmem

[Graham Bloice <graham.bloice () trihedral com>]

On 23 April 2014 14:14, Evan Huus <eapache () gmail com> wrote:

> On Wed, Apr 23, 2014 at 9:11 AM, Anders Broman
> <anders.broman () ericsson com> 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

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe