Ethereal-dev: RE: [Ethereal-dev] Ethereal performance, after Guy's changes ...
| From: Guy Harris
|
| 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 we require that protocol fields must start with the protocol name, we
might further simplify filtering: proto.sub.proto.field can only be true if
proto matches...
| 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.
