Wireshark · Ethereal-dev: Re: [Ethereal-dev] Ethereal performance, after Guy's changes ...

[Guy Harris <guy@xxxxxxxxxxxx>]

On Nov 19, 2003, at 11:52 AM, didier wrote:

> But it doesn't solve the main issue: filters are slow.

Filters will probably be always slower than no filters, so "filters are 
slow" will probably always need two fixes:

	1) make filters faster

	2) don't filter if you don't have to.

> Can we tell from a filter if we need to fully decode a protocol?

Currently, no.

However, the filter expression "tcp", for example, is known to be true 
as soon as the TCP dissector is called, so an expression that's always 
true if "tcp" is true, e.g.

	tcp || {anything}

or

	{anything} || tcp

is known to be true as soon as the TCP dissector is called.  If the 
protocol tree is being constructed *solely* for filtering (which 
includes display filters, read filters, color filters, tap filters, 
etc.), and not for, for example, display, or handing to a tap or 
otherwise processing in its entirety, we could, in theory, quit as soon 
as an expression is known to be true.  To evaluate "tcp" on a packet 
that doesn't contain TCP requires that the packet be dissected in its 
entirety (unless we have, in effect, a "call graph" for protocols, and 
we find a protocol whose subgraph of callees does not include TCP), but 
that shortcut might still help.

Similar things could perhaps be done for fields that aren't protocols.

If an expression involves only fields that are protocols, we could 
perhaps construct a list of protocols, rather than a full protocol 
tree.  We could perhaps generalize that by marking some non-protocol 
fields as "commonly filtered on", and add them to that list, although 
in that case we'd need to make sure we put those fields into the other 
data structure even if we're not building a protocol tree.

That data structure might also be cheaper to save as something attached 
to the "frame_data" structure than a full protocol tree, as per 
Ronnie's suggestion.

> What about a display attribute in the tree structure, with it we might 
> 'if enclosed' a lot of expensive sprintf calls.

The sprintf calls in "proto_tree_add" and "proto_item_append" routines 
are already made only if we're constructing a "visible" protocol tree; 
see the checks for "fi->visible" in "epan/proto.c" (and hidden items 
*never* have that constructed).  "Visible" protocol trees are 
constructed only by "print_packets()", "match_protocol_tree()", 
"select_packet()", and "wtap_dispatch_cb_write()" in Tethereal *if* the 
"-V" flag was specified; the tree constructed when reading the file and 
when filtering isn't "visible".