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

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

From: Ian Schorr <ethereal@xxxxxxxxxxxxx>
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 =)

Thanks,
Ian