On Sat, Oct 12, 2013 at 6:31 PM, Jakub Zawadzki <[email protected]> wrote: > On Sat, Oct 12, 2013 at 05:08:04PM -0400, Evan Huus wrote: >> On Sat, Oct 12, 2013 at 12:29 PM, Evan Huus <[email protected]> wrote: >> > Now I'm wondering how much of this could be alleviated somehow by a more >> > efficient tree representation... >> >> The answer is apparently lots :) > > We've already had similar benchmark result done, while removing emem slabs: > http://www.wireshark.org/lists/wireshark-dev/201303/msg00101.html > http://www.wireshark.org/lists/wireshark-dev/201303/msg00105.html
Yes, that's actually why I looked at doing this. I just couldn't find the references anymore :P >> I tweaked some things in r52568, r52569 and r52573 that had a fairly >> substantial improvement when dissecting with a tree. "tshark -V" is as >> much as 18% faster in my tests, and filtering should improve a little >> as well, though that is much harder to measure. > > Still good we regain this performance (and even better tree free now is O(1)), > even if tshark -V might be not normal use case. Thanks. tshark -V might not be, but we do allocate an incomplete tree when doing filtering so it has some practical effect in the GUI as well. Although actually tree free is not yet O(1) unfortunately. We have to walk the tree still to free the finfo->value pointers or else they are leaked. I couldn't find an easy way to safely allocate them in the same wmem pool, and the patch was getting big and complex enough as it was. Actually on a quick test (ignoring the leaks) removing that step doesn't seem to have a statistically noticeable effect anyways. I guess the actual iteration is fast enough if you aren't doing much work at each step. Evan ___________________________________________________________________________ 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
