bother splitting. This greatly simplifies the logic, trims another 4% off the
fast path, and doesn't actually affect the results at all because of the way we
pad for alignment anyways.
svn path=/trunk/; revision=51216
if the right-hand merge target was there originally. This brings memory usage
down another ~40% when running the heavy test suite.
This also lets us extract the master-list check out of unfree() since it is now
only relevant at a single caller, and turns unfree into the more understandable
remove_from_recycler().
svn path=/trunk/; revision=51104
Removes one branch from the hot path, deduplicates one function call in the cold
path by effectively falling through, and makes it more obvious what the code is
actually trying to do.
svn path=/trunk/; revision=51013
to override that to simple for valgrinding (we still force the allocator in the
allocator and timing tests, of course).
svn path=/trunk/; revision=50971
Move a few assignments around to avoid one extra subtraction. I suspect having
the two if statements next to each other is friendly to the compiler's optimizer
as well.
Shaves ~1.3% off my timing tests, bringing the new design *very* close to the
old one in raw allocation speed.
svn path=/trunk/; revision=50961
unobtrusive if statement got dropped. Without it the allocator exhibits the old
bad behaviour of 3x memory usage and heavy fragmentation.
We want it back, thank you very much.
svn path=/trunk/; revision=50960
What was becoming apparent as more dissectors started using wmem was that the
old block allocator design had issues with memory fragmentation. This keeps the
same underlying memory layout, but completely changes how free blocks are kept.
It runs about 3% slower in my tests (still an order of magnitude faster than
g_malloc) but uses about 1/3 the memory.
I suspect some simple optimizations could reclaim that 3% as well - the design
is fast, but I did not code particularly for speed.
Thoroughly tested with the existing test suite (which caught half a dozen bugs
in my first draft) so it should actually work!
svn path=/trunk/; revision=50955
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
From the comment above wmem_tree_insert32_array():
* If you use ...32_array() calls you MUST make sure that every single node
* you add to a specific tree always has a key of exactly the same number of
* keylen words or things will most likely crash. Or at least that every single
* item that sits behind the same top level node always have exactly the same
* number of words.
So clearly generating thousands of keys with random lengths while testing is
going to cause problems. Generate a set of random lengths, then use those
lengths consistently (but still generating random keys of those lengths).
Should hopefully fix the intermittent build-bot failures.
(unfortunately this does not manifest nicely, and I cannot see an easy way to
assert it so that we catch other people trying to use different-length key
subtrees)
svn path=/trunk/; revision=50184
Put in a whole bunch of stderr output in the wmem tree tests in the hopes that
the next time one of the buildbots randomly (and irreproducibly) fails on this
step we'll have at least a bit of a hint as to where it happened.
svn path=/trunk/; revision=50131
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8824
Convert bluetooth emem trees to wmem trees.
Add modelines and fix indentation.
Correct typo in wmem_tree.h that still referred to emem.
svn path=/trunk/; revision=50076
it is out of scope, they just can't *allocate* in the pool. This is necessary
because file-scope trees (migrating from emem) are set up on program
initialization when there is no file in scope - they need to initialize with the
handle, they just won't use it until a file is actually in scope.
svn path=/trunk/; revision=50046
enum for the color (red/black). Don't use bitfields since they don't save us
much (if anything) in terms of space and don't nest the fields in their own
anonymous struct.
svn path=/trunk/; revision=50011
Evan Huus