On 23 April 2014 14:14, Evan Huus <[email protected]> wrote: > On Wed, Apr 23, 2014 at 9:11 AM, Anders Broman > <[email protected]> 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 <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
