On Sat, Oct 12, 2013 at 6:31 PM, Jakub Zawadzki
<darkjames-ws@xxxxxxxxxxxx> 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 <eapache@xxxxxxxxx> 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