Re: [Wireshark-bugs] [Bug 11980] The filtering speed is impacted by commit b344107d757466e0768a3ef8927852479e926cf6 (Make color filters part of dissection)

[Peter Wu <peter () lekensteyn nl>]

On Sun, Jan 10, 2016 at 04:43:01PM +0100, Anders Broman wrote:
> Den 10 jan 2016 14:50 skrev <bugzilla-daemon () wireshark org>:
> > Comment # 6 on bug 11980 from Peter Wu
> >
> > You are right, coloring always need to happen (whenever color rules
> > exist).
> > (What about tshark? Colors are normally not shown, but if the two
> > frame.coloring_rule fields are shown in the frame tree/columns, should the
> > color calculation also be done?)
>
> Do we know if it's a tshark run? If so skip the fields?

I have not yet discovered how to detect this. In the proposed patch
which adds frame_data.flags.need_colorize, colorization is skipped for
tshark because the flag is not set.

> > For a start, to calculate on the first pass
> > (pinfo->fd->flags.visited == 0).
> > This did not work because the fields from the color filter are not
> > primed yet.
> > Possible fix: always invoke dfilter_prime_proto_tree before
> > epan_dissect_run{,_with_taps} (similar to epan_dissect_prime_dfilter).
> >
> > The next problem is that the applicable color may change during subsequent
> > redissections.
>
> Do the opposite, only run on second pass? Is it only needed for visible
> frames?

That could slow down taps I think. It is only needed for visible frames
indeed.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe