Wireshark-dev: Re: [Wireshark-dev] [Wireshark-bugs] [Bug 11980] The filtering speed is impacted
On Sun, Jan 10, 2016 at 04:43:01PM +0100, Anders Broman wrote:
> Den 10 jan 2016 14:50 skrev <bugzilla-daemon@xxxxxxxxxxxxx>:
> >
> > 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
