This has two expected uses:
- Many current users of wmem_tree don't actually need the predecessor lookup
it provides (the lookup_le function family). A hash map provides straight
insertion and lookup much more efficiently than a wmem_tree when predecessor
lookup isn't needed.
- Many current users of glib's hash table and hash functions use untrusted data
for keys, making them vulnerable to algorithmic complexity attacks. Care has
been taken to make this implementation secure against such attacks, so it
should be used whenever data is untrusted.
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).
Change-Id: I2d67a0d06029f14c153eaa42d5cfc774aefd9918
Reviewed-on: https://code.wireshark.org/review/1272
Reviewed-by: Evan Huus <eapache@gmail.com>
There is confusion about API usage, and problems on my part concerning whether
keys should be compared signed or unsigned, and how to do that efficiently.
Unsigned keys in particular were behaving oddly.
Change-Id: I075693bbd04c15f79f24f9a24006003a914cc572
Reviewed-on: https://code.wireshark.org/review/924
Reviewed-by: Evan Huus <eapache@gmail.com>
(Using sed : sed -i '/^\# \$Id\$/,+1 d') (start with dash)
Change-Id: Ia4b5a6c2302f6a531f6a86c1ec3a2f8205c8c2dd
Reviewed-on: https://code.wireshark.org/review/881
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This is a tree implementation intended to replace the current red-black tree in
wmem_tree (which was inherited from emem), assuming there are no regressions.
Splay trees bubble recently accessed keys to the top, and as such have a number
of very nice properties: https://en.wikipedia.org/wiki/Splay_tree
This implementation is a variant known as "independent semi-splaying", which has
better practical performance. It should do about as well as the red-black tree
for random insertions and accesses, but somewhat better for patterned accesses
(such as accessing each key in order, or accessing certain keys very
frequently).
There are a few other changes relative to the red-black tree implementation that
are worth mentioning:
- Instead of requiring complex keys to be split into guint32 chunks and doing
this weird trick with sub-trees, I let the keys be arbitrary pointers and
allowed the user to specify an arbitrary comparison function. If the function
is NULL then the pointers are compared directly for the simple integer-key
case.
- Splay trees do not need to store a red-black colour flag for each node. It is
also much easier to do without the parent pointer in each node. And due to
the simpler system for complex keys, I was able to remove the "is_subtree"
boolean. As such, splay nodes are 12 bytes smaller on 32-bit platforms, and
16 bytes smaller on a 64-bit platform.
All done in about half the lines of code.
Change-Id: I89fb57e07d2bb7e3197190c7c2597b0c5adcc03b
Reviewed-on: https://code.wireshark.org/review/758
Reviewed-by: Evan Huus <eapache@gmail.com>
The overhead is not large, and it makes append much faster (O(1) vs O(n)).
It also will make a queue easy to add, which I need for a dissector I'm
writing...
svn path=/trunk/; revision=50744
recurring callbacks, I suspect most other potential uses will be once-only, so
make that possible, and improve the documentation on the remaining issues.
Also separate out the code into its own files and the testing into its own
test case.
svn path=/trunk/; revision=49209
the behaviour emem has for seasonal trees, which is that the master tree
structure is not actually seasonal - it is permanent. When the seasonal memory
pool is cleared, the root node pointer in all of these permanent trees is set
to NULL, and the pool takes care of actually freeing the nodes.
Wmem can now mimic this by allocating the tree header struct in epan_scope(),
allocating any node structs in file_scope(), and registering a callback on
file_scope() that NULLs the pointer in the epan_scope() header. Yes, this is
confusing, but it seemed simpler than adding manual callback registrations to
every single dissector that currently uses seasonal trees.
The callbacks may also be useful for other things that need cleanup (I'm
thinking resource handles stored in wmem memory that need to be fclosed or
what-have-you before they the handle is lost).
As indicated by the number of caveats in README.wmem, the implementation
probably needs a bit of work to make it safer/saner/more-useful. Thoughts
(or patches!) in this direction are more than welcome.
svn path=/trunk/; revision=49205
(removed in r48218) which did nothing particularly useful. Also lets us remove
another debugging environment variable.
svn path=/trunk/; revision=48219
yet initialized because I can't figure out where the enter() and leave() calls
should go - the obvious place in packet.c causes a lot of assertion errors.
svn path=/trunk/; revision=45879