Re: [Ethereal-dev] Back to performance...

["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

----- Original Message ----- 
From: "Ian Schorr"
Subject: Re: [Ethereal-dev] Back to performance...


> Some taps, for example the "Conversations" and "Endpoints" options
> (particularly with GTK2) can be fairly costly.  If I have a
> conversations list up, a couple of SRT lists built, and an IO Graph
> running, it can take me twice as long to refilter after creating a new
> display filter as when the taps aren't built, though retapping
> accomplishes nothing.  The performance hit can still be quite significant.
>
> I've been running builds using my simple file.c patch here and the
> difference is quite noticeable.

What does that file.c patch do?

I think that for these function, the main part of processing made during
post-load analysis, which mainly is
refiltering over and over, and which today requires re-dissection of all
packets in the capture could be sped up
if one would remember the full dissection data and all fields (not only
those part of the filter string(s) and thus no edt pruning)
and not throw them away when moving over to the next packet in the list.

This should in theory make re-filtering much faster.

Drawback would very likely be that memory usage would be significantly
elevated but this might be a price worth paying
to speed up re-filtering of captures. (Many users load a capture once and
then filter that capture dozens of times)
This behaviour could be made controllable from preferences and the default
would be "optimize for memory usage (current model)"
or "optimize for speed".

A further optimization, to prevent the memory usage from completely
exploding, could be that during dissection, if a certain field is larger
than
(random number) 20 bytes, then the data for that field would not be
stored/remembered but instead that field would be marked as "value
forgotten"
and if a field marked as such is filtered for, then it would automatically
revert back to the original model.