On Mon, Sep 09, 2002 at 06:42:48PM +1000, Ronnie Sahlberg wrote: > There is a problem though with tap in that performance is really affected if > the tap listeners > use filters. I dont know epan_dissect_prime_dfilter() and friends well > enough to be able to fix this. Could you look at it? > See tap_push_tapped_queue() > in the inner loop there is an if-statement checking if the listener had > specified a filter and > if so it would do a full : > epan_dissect_new() > epan_dissect_prime_dfilter() > epan_dissect_run() <= This one takes quite some time I think. > dfilter_apply_edt() > For each and every such tap listener. > Well, you see the problem, we do a full and expensive dissection of the > entire packet just because we only want to apply a filter.
To apply a display filter, you *have* to do a dissection of the entire packet, as filters act on protocol trees. Presumably what you meant was "we do a full and expensive dissection of the entire packet for each filter we want to apply, rather than doing one dissection and applying multiple filters". As far as I can tell, "dfilter_prime_proto_tree()" doesn't modify the dfilter to which it's passed a pointer (it might be worth making its "df" argument a "const dfilter_t *", to emphasize that), and that's what's called by "epan_dissect_prime_dfilter()". As such, I see no reason why you can't make multiple calls to "epan_dissect_prime_dfilter()" with the same tree, one for each filter for which you're priming the tree. Then you'd only need to make one 'epan_dissect_new()" call, and only one "epan_dissect_run()" call.
