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

Note: This archive is from the project's previous web site, This list is no longer active.

From: Ian Schorr <[email protected]>
Date: Fri, 23 Jul 2004 19:05:06 -0400
Hey guys,

I'm trying to get back to looking at performance improvements. I know a lot of people (myself included) that are tortured by the amount of time it takes to work with large (200,000+ frame, reasonably complex protocol) traces, so I'm pretty motivated to see performance improved =)
Looking to get some input from the dev community here.

One area I'm interested in is tap generation behavior and eliminating unnecessary processing. Do any of the current taps in any way rely on the active display filter AFTER being initially built? If not, can we do some things to separate tap processing from other functions?
At the moment we call the taps and force them to reinitialize and 
rebuild every time the user changes display filter, color filters, 
reftime, etc.  This seems inefficient particularly since some tap 
listeners consume considerable CPU, and I don't see any reason to 
rebuild them if we're simply trying to rebuild the packet list.
In the other direction, is there any reason that the packet list needs 
to be rebuilt every time a new tap listener is added or changed in some 
way?  In the profiling I've been doing today on OS X with GTK+ 2.4, 
rebuilding the packet list consumed something like 25-32% of total CPU 
time while reprocessing.  It seems that this could be avoided.
I'm assuming it works the way it does at the moment because it was 
easy, but would it make sense to separate out the 
redissection/reprocessing, packet list handling, and tap calling 
processes much more than we do currently?  (I'm not sure if I want to 
suggest allowing the taps to be moved into independent threads yet tho