Interesting.
Four comments:
1, One would have to be a bit careful with where one uses
proto_tree_is_null() since there are instances where one protocol
dissector calls functions/subdissectors from other protocols. For
example NLM will call the dissector for NFS filehandles from the NFS
dissector. This would need to be documented. Can you write a README
for discussion on this?
2, proto_tree_is_null() would need a better more appropriate name.
3, comment in your patch: i really think you need to do refcounting
for these items. I am not sure, but one might do refcounting just to
be on the safe side.
The refcounting might be as easy to implement as just
incrementing/decrementing hfinfo->infilter and letting ==0 mean not
used at all in any filter. Would need to check that that would work.
4, proto_tree_is_null() is a too blunt instrument, it either enables
all fields or none fields. In addition to that one might also consider
putting
if(!( ->visible or ->infilter ))return
at the beginning of the proto_tree_add_ functions as well to further
reduce the number of calls made.
This might reduce the filter overhead even further.
On Wed, 16 Mar 2005 21:52:40 +0000, didier <dgautheron@xxxxxxxx> wrote:
> Hi
> Filters are slow because dissectors are called with a non null tree
> parameter.
> If you assume that:
> 1) in a frame with A- B -C -D protocols and a filter C.x you can only
> fully decode C
> 2) if a filter field is only a protocol type ie tcp, afp you don't need to
> you can speed it a lot
