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

[Ian Schorr <ethereal@xxxxxxxxxxxxx>]

Lars Roland wrote:

> > So how do we move forward with this?  So far no one seems to disagree.
> >
> > Should we allow tap authors more time to respond?  Does someone need 
> > to do a more thorough review code to determine if no taps do, in 
> > fact, depend on the current display filter?  Should we make a design 
> > decision that tap listeners should not depend on the current display 
> > filter, or a seperate function should be created (or perhaps my 
> > "retap" flag should be replaced with something that is a bit more 
> > intelligent, and allows only specific taps to be rebuilt if needed)?
> I think all taps or at least most of them don't depend on the display 
> filter. I am just not so sure about the conversation, hostlist and rtp 
> taps.
> However I don't think you will get only a small performance 
> improvement as only the xxx_packet functions of the taps are called a 
> lot. These routines are usually quite small and fast compared to 
> dissector funtions which are called anyway when you change the display 
> filter. But go ahead   , I'd like to see the results.
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.

Ian