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
