ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [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: Thu, 5 Aug 2004 12:42:50 -0400
On Aug 5, 2004, at 3:26 AM, Ronnie Sahlberg wrote:

What does that file.c patch do?

Adds a flag, "retap", to rescan_packets(), that indicates whether tap listeners should be told to retap when packet rescan happens. The intention here is to allow retapping not to be forced to occur any time packet reprocessing occurs, which is pointless and wasteful in many cases. It also changes the calls to rescan_packets() made by the colorize, reftime update, display filter change routines to not cause retapping to happen.

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.

I agree 110%. Let's do that as well. However, I still don't see why we need to force tap reprocessing unnecessarily, which as I mentioned earlier can be quite costly (and will remain costly if new taps are added that impose even greater CPU overhead than the current ones)

Ian