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

Ethereal-dev: [Ethereal-dev] Re: Improving filter speed

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

From: ronnie sahlberg <ronniesahlberg@xxxxxxxxx>
Date: Tue, 29 Mar 2005 09:08:16 -0400
updated version of the patch to avoid core dump if people try to
access parents in a faked tree



On Tue, 29 Mar 2005 08:06:23 -0400, ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
> Using my slightly modified version of Didiers patch :
> 
> I did another quick test  now using Ethereal and only having the
> Ethernet, IP and TCP protocls enabled and all other protocols
> disabled.
> All 500k + packets in the trace were TCP packets.
> The trace was 500MByte in size.
> I had full TCP analysis enabled (which i know is not optimally tweaked
> for performance yet)
> I also had the color filter "tcp.analysis.flags" enabled.
> 
> 
> Original version of ethereal took  140 seconds on average to read the
> capture file and apply the color filter.
> 
> With the patch applied the same operation took on average 79 seconds.
> 
> Pretty significant increase in filtering speed.
> 
> 
> Unless someone objects or rises concerns or can show a regression with
> this patch I intend to check it in in a day or two so that colleagues
> can test the buildbot version on windows.
> 
> 
> 
> On Tue, 29 Mar 2005 04:04:51 -0400, ronnie sahlberg
> <ronniesahlberg@xxxxxxxxx> wrote:
> > On Mon, 28 Mar 2005 16:09:23 +0000, didier <dgautheron@xxxxxxxx> wrote:
> > > ronnie sahlberg wrote:
> > > > Attached is a test patch, please test it.
> > > > 
> > > > Didier, this is a refactored version of your patch, it differs from
> > > > your original patch in that it
> > > > 1, does refcounting on whether fields and parent protocols are used or
> > > > not. (not neccessary here but might be useful in the future)
> > > yes but you lose :
> > > If the only field referenced is the protocol name then return NULL for
> > > tree.
> > > This one help a lot with color filters where a lot of rules are only 
> > > protocol name, at least here.
> > 
> > Ok, That can easily be added in the future.
> > 
> > > 
> > > > 2, renames the new variable and the function.
> > > > 3, it will use the refcounting information inside
> > > > proto_tree_add_item() and friends and avoid doing unneccessary work
> > > > for the fields that are not used.
> > > > (just checking per protocol is not optimal since some protocols   SMB
> > > > and H225 etc have many thousand filter fields each)
> > > You can't use
> > > TRY_TO_FAKE_THIS_ITEM(tree, hfindex);
> > > with all protocols.
> > > If you have an IPX catpure it will dump a core because it uses functions
> > > like proto_item_get_len(), with TRY...  PITEM_FINFO(pi) is NULL.
> > 
> > I have changed the patch to only fake the item iff PITEM_FINFO(pi) is not
> > NULL.
> > 
> > I dont think that this was absolutely neccessary since the only thing
> > that has this as NULL would be the top tree  and the only thing
> > attached to the top tree are nodes of type FT_PROTOCOL which the
> > previous patch checked for anyway.
> > 
> > Please test it.
> > Please send me any capture files where this patch makes ethereal crash.
> > 
> > 
> > > 
> > > Didier
> > > 
> > >
> > 
> >
>

Attachment: filter_performance.diff.gz
Description: GNU Zip compressed data