Change-Id: Ied0428324c14f248bf6857fd288b4fb5d4591230
Reviewed-on: https://code.wireshark.org/review/7033
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Lua-created tvbuffs should be kept around for the duration of pinfo's
lifetime, instead of only for the duration of frame dissection. So
instead of using the frame dissector's frame_end_routine, we'll register
a callback to wmem for pinfo pool's allocator.
Bug: 10888
Change-Id: I3e9db671c3f2a7cab9e258aca17f3be8acaf2417
Reviewed-on: https://code.wireshark.org/review/6768
Petri-Dish: Hadriel Kaplan <hadrielk@yahoo.com>
Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org>
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Hadriel Kaplan <hadrielk@yahoo.com>
Tested-by: Hadriel Kaplan <hadrielk@yahoo.com>
That way, we don't do locale-sensitive case-insensitivity (yes, the
locale can affect case-mapping - in a Turkish locale, "I" isn't the
upper-case version of "i", for example).
Change-Id: I5f7663e85160558ff3769617f924e45049c9c384
Reviewed-on: https://code.wireshark.org/review/4843
Reviewed-by: Guy Harris <guy@alum.mit.edu>
The main site URI scheme is now https. Update the URL in some other
places while we're here.
Change-Id: Ib03d4fd1c58dabd3cf5050dc4f79216e0b94d525
Reviewed-on: https://code.wireshark.org/review/4133
Reviewed-by: Gerald Combs <gerald@wireshark.org>
Some of the allocators are close enough that a little bit of system load at the
time of the test was enough to throw them off, and it was causing unnecessary
buildbot failures. Benchmarking on real-world cases at the time of
implementation (as well as reliable "average" results on the buildbots) has left
me confident that block_fast is, in fact, faster than block, which is faster
than simple/strict.
Additionally, the allocators are effectively "done" and unlikely to change, so
the possibility of uncaught performance regressions is low.
Change-Id: I144ea4cd9d6000edc4075ed682ce6a4aeaf5e28a
Reviewed-on: https://code.wireshark.org/review/3356
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Apparently the new win8 vm has a *very* low-resolution timer, and the allocators
are indistinguishable at the previous amount of work.
Change-Id: If4e5bb8f85b1f0d39658f54001c88f42ffddfc47
Reviewed-on: https://code.wireshark.org/review/2768
Reviewed-by: Evan Huus <eapache@gmail.com>
Change-Id: Ie3f60f66f0f4a572098d1d7425c53aaf51bdb747
Reviewed-on: https://code.wireshark.org/review/1846
Reviewed-by: Michael Mann <mmann78@netscape.net>
As it turns out, we do occasionally need it.
Bug:10115
Change-Id: Ifec79e4d2470bbc09f15674534d01418a6571a0d
Reviewed-on: https://code.wireshark.org/review/1688
Reviewed-by: Evan Huus <eapache@gmail.com>
Fix the clang warning
epan/wmem/wmem_allocator_simple.c:49:27: error: equality comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
if ((allocator->count == allocator->size)) {
~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~
We might want to add -Wno-parentheses-equality to the compiler flag
list but I'm not sure if doing so would hide valid problems.
Change-Id: Id59b55af1411f13309fbec77870f869e04a6f49f
Reviewed-on: https://code.wireshark.org/review/1717
Reviewed-by: Gerald Combs <gerald@wireshark.org>
As Jakub pointed out, our +1/-1 logic for null terminators wasn't quite right.
Also be sure to re-copy the va_list parameter if we need to re-use it, as
otherwise things break oddly.
Change-Id: Ibeaa95af602f565791e9378a6cfce434f13025eb
Reviewed-on: https://code.wireshark.org/review/1670
Reviewed-by: Evan Huus <eapache@gmail.com>
- g_vsnprintf()[1] buffer size can includes space for terminating NUL,
this simplifies code, and fix problems with string truncation
- g_vsnprintf() returns number of bytes without terminating NUL, so we
need to do + 1
- second g_vsnprintf() call use already consumed 'ap2' va_arg, which
makes wmem_strdup_vprintf() doesn't work/ crash for FORMATTED string length > 80
[1] https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-vsnprintf
Change-Id: I0ebb7f452e3e89c9b55f8ac889166f02e8a7c982
Reviewed-on: https://code.wireshark.org/review/1667
Reviewed-by: Michael Mann <mmann78@netscape.net>
cost by more than half.
Change-Id: I6ad2ae407325d2091ffb60919cb3ed74f78f39fa
Reviewed-on: https://code.wireshark.org/review/1662
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Instead of maintaining a hash table, just alloc a really big array of pointers.
This is theoretically bad since it means frees and reallocs become O(n), but in
practice it makes the capture from bug 10098 run about 20% faster under
valgrind. This makes sense, since the workload is heavily dominated by
allocations, and most frees/reallocs are recently allocated (so they will be
found quickly at the beginning of the scan).
Bug:10098
Change-Id: I7097ad0653d3fb5f4f723cc84046cbc4450e3494
Reviewed-on: https://code.wireshark.org/review/1602
Reviewed-by: Anders Broman <a.broman58@gmail.com>
It appears that on some platforms the timer underlying g_test_timer() is
relatively low-precision, so the small amount of work that we were previously
doing was not enough for the timer to provide a useful value.
Bumping the amount of work should provide more meaningful values, and the whole
timing step still takes only a few seconds.
Change-Id: Idce1386eaa33add845d9a2758b0beb72bbf370d6
Reviewed-on: https://code.wireshark.org/review/1523
Reviewed-by: Evan Huus <eapache@gmail.com>
Follow-up to g19e650f43adf23b0aa92821bff0cc389643944f6 since the fuzz-bot is
still failing.
Change-Id: I2d05a861b0edf50ce734b682e6e3e33729bf6771
Reviewed-on: https://code.wireshark.org/review/1503
Reviewed-by: Evan Huus <eapache@gmail.com>
- manually inline wmem_block_fast_add_to_block_list, it was only two lines and
only called twice, so the function boilerplate was outweighing the abstraction
- change free_all to release all but one block to the OS immediately, making gc
a no-op; the alloc logic doesn't reuse later blocks anyways, so this was
effectively a leak
Change-Id: I033fbb2f3d87e58c7346cba10f2c710eaaa49e9f
Reviewed-on: https://code.wireshark.org/review/1499
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Double linked list was required by jumbo allocation.
No support for jumbo -> no need for double linked list -> have only 'next' pointer in header.
Change-Id: I48a0f468ebba9db3a63548d8e7307b6424c759ed
Reviewed-on: https://code.wireshark.org/review/1495
Reviewed-by: Evan Huus <eapache@gmail.com>
I believe the XP buildbot failures are simply running out of memory, so
hopefully reducing the number of iterations should be enough to let it finish
reliably.
Change-Id: I40af789d528c2623e95f153529205b5e617c6e02
Reviewed-on: https://code.wireshark.org/review/1496
Reviewed-by: Evan Huus <eapache@gmail.com>
For packet-scope allocation, there's no need to support realloc(), free()
cause memory will be garbage collected after packet dissection.
(and this allocator is much faster than full block allocator).
Change-Id: I73fdf708c3077f48f55bdcc71f4fa859e4ac2335
Reviewed-on: https://code.wireshark.org/review/1428
Reviewed-by: Anders Broman <a.broman58@gmail.com>
We now have to call wmem_init in order to randomly seed the values for wmem_map.
This means we can no longer rely on the lack of override, so we have to force
the right allocator type when testing/timing the allocators themselves.
Change-Id: I005034465b0a98f19876899b96ef65b3e4b1d759
Reviewed-on: https://code.wireshark.org/review/1468
Reviewed-by: Anders Broman <a.broman58@gmail.com>
As suggested by Anders, in the case of repeated calls to wmem_strbuf_append_c
(and other functions which append very little data) the growth check was a
substantial portion of the over-all running time. By short-circuiting the check
in the case where growth isn't needed (as opposed to letting it fall-through
naturally) we shave ~25% off the cost of such repeated calls in my benchmarks.
The function (wmem_strbuf_grow) is inline, so the compiler should be able to
optimize each caller individually for the short-circuit.
Change-Id: I76419020f4d8fa675906eb77798969b6c61c7732
Reviewed-on: https://code.wireshark.org/review/1467
Reviewed-by: Anders Broman <a.broman58@gmail.com>
"if (G_UNLIKELY(...))" triggers an extraneous parentheses warning when
compiling with XCode's clang-500.2.75. From looking at the macro
definition we *should* be able to get rid of the outer parentheses
everywhere.
Change-Id: I710e1cc391e1167c1243c4ddb032f2831f0a9498
Reviewed-on: https://code.wireshark.org/review/1432
Reviewed-by: Gerald Combs <gerald@wireshark.org>
For 'x' equal to 0, HASH() macro also returns 0 which makes wmem map O(n).
When random generator will return 0 just use 1.
Change-Id: If484091352a719aea27135a705d37ff4c184a13b
Reviewed-on: https://code.wireshark.org/review/1387
Reviewed-by: Michael Mann <mmann78@netscape.net>
Always call $(top_srcdir)/tools/checkAPIs.pl with -sourcedir=$(srcdir)
from Makefile.am to allow out-of-source 'make checkapi'.
Change-Id: I60d7e0079984a8ededdacf4517a0738486fa7973
Reviewed-on: https://code.wireshark.org/review/1294
Reviewed-by: Anders Broman <a.broman58@gmail.com>
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>
Rather than using a hash table, which is overkill and slow, embed a
doubly-linked-list in the prefix structure.
On my tests with some random capture file and tshark -nxVr:
- normal block allocator: ~2.1 seconds
- old (slow) strict allocator: ~4.2 seconds
- new (fast) strict allocator: ~2.8 seconds
The buildbot will thank me :)
Change-Id: I2fb42229c4ee4c40bbe45ba04b7848792998eaa9
Reviewed-on: https://code.wireshark.org/review/1251
Reviewed-by: Anders Broman <a.broman58@gmail.com>
epan/wmem/wmem_strutl.h:85:63: error: parameter 'str' is already documented [-Werror,-Wdocumentation]
epan/wmem/wmem_strutl.h:85:27: note: previous documentation
epan/wmem/wmem_strutl.h:90:39: error: parameter 'str' is already documented [-Werror,-Wdocumentation]
epan/wmem/wmem_strutl.h:85:57: note: previous documentation
epan/wmem/wmem_strutl.h:83:11: error: parameter 'allocator:' not found in the function declaration
epan/wmem/wmem_strutl.h:83:11: note: did you mean 'allocator'?
epan/wmem/wmem_strutl.h:84:11: error: parameter 'str:' not found in the function declaration [-Werror,-Wdocumentation]
epan/wmem/wmem_strutl.h:85:11: error: parameter 'len:' not found in the function declaration [-Werror,-Wdocumentation]
epan/wmem/wmem_strutl.h:85:11: note: did you mean 'len'?
Change-Id: Id2888c5967c94c48f9b53957c8be361bbebd3488
Reviewed-on: https://code.wireshark.org/review/1151
Reviewed-by: Evan Huus <eapache@gmail.com>
wireshark/epan/wmem/wmem_stack.h:39: Warning: group wmem-stack: ignoring title "Stack-bbab" that does not match old title "Queue"
Change-Id: I9376651d89d9df21aeca82ddb952c230d546169a
Reviewed-on: https://code.wireshark.org/review/1130
Reviewed-by: Anders Broman <a.broman58@gmail.com>
C90 permits plain %f for doubles. Thanks to Alexis for pointing this out.
Change-Id: I3f927b0a50e5764c2297c7f9d680c6363ba9fd0e
Reviewed-on: https://code.wireshark.org/review/1073
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
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 previous macro gave the correct alignment, but there was one case where it
would add a whole block of unnecessary ALIGN_SIZE bytes. The new one is also
slightly faster to compute.
Benchmark win of about 3%.
Change-Id: I5d8bad0f78dc0e383e14c2c7a951328a06400020
Reviewed-on: https://code.wireshark.org/review/492
Reviewed-by: Evan Huus <eapache@gmail.com>
(Using sed : sed -i '/^ \* \$Id\$/,+1 d')
Fix manually some typo (in export_object_dicom.c and crc16-plain.c)
Change-Id: I4c1ae68d1c4afeace8cb195b53c715cf9e1227a8
Reviewed-on: https://code.wireshark.org/review/497
Reviewed-by: Anders Broman <a.broman58@gmail.com>
It has been extremely well-tested at this point, and is a very hot code path so
the performance gain is measurable (~1-2% on most captures I tried).
Change-Id: I2f5e03d2f348f56e740bf0dfbc83a4fd9cc8c5a9
Reviewed-on: https://code.wireshark.org/review/499
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Alexis La Goutte