On Sat, Oct 12, 2013 at 12:29 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
> On Sat, Oct 12, 2013 at 11:46 AM, Anders Broman <a.broman@xxxxxxxxxxxx> wrote:
>> Just looking at performance in general as I got reports that top of trunk
>> was slower than 1.8.
>> Thinking about it fast filtering is more attractive as long as loading isn't
>> to slow I suppose.
>> It's quite annoying to wait 2 minutes for a file to load and >=2 minutes on
>> every filter operation.
>
> Ya. It was quite surprising to me to find out how much data we're
> generating and throwing away on each dissection pass. Now I'm
> wondering how much of this could be alleviated somehow by a more
> efficient tree representation...
The answer is apparently lots :)
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.
This may or may not fix the complaints you've been getting, but it's a
good improvement to have regardless.
Cheers,
Evan