Comment # 4
on bug 11980
from Peter Wu
I did some tests and found that the new code was marginally faster when no
display filters are applied. With display filters applied, the performance is
significantly worse.
randpkt -b 1000 -c 500000 -t tcp rand.pcap
master: v2.1.0rc0-1404-g10bb1f2
revert: v2.1.0rc0-1404-g10bb1f2 + revert v2.1.0rc0-1282-gb344107
The times below are the "Load time" as taken from the status bar after loading
the file. An empty configuration was used.
wireshark -r rand.pcap
master: 5.22s (sd=.348) [5.65, 4.974, 4.906, 5.36]
revert: 5.41s (sd=.281) [5.75, 5.27, 5.51, 5.108]
wireshark -r rand.pcap -Y http (note: no matches)
master: 8.16s (sd=.143) [8.318, 8.122, 7.983, 8.217]
revert: 6.70s (sd=.031) [6.693, 6.742, 6.709, 6.667]
Out of curiousity I also disabled color filters by writing an empty
"colorfilters" file.
(no filter)
master: 5.45s (sd=0.342) [4.98, 5.49, 5.52, 5.8]
revert: 5.45s (sd=0.408) [5.96, 5.6, 5.11, 5.133]
(filter http)
master: 6.63s (sd=0.066) [6.661, 6.561, 6.711, 6.604]
revert: 6.80s (sd=0.068) [6.868, 6.725, 6.836, 6.753]
The most expensive call is dfvm_apply (called via
color_filters_colorize_packet). These optimization can be checked:
- Always calculate when the frame details are requested (tree != NULL)
- Skip if no color filters are in use (already done).
- Skip when no column uses color filter field.
The patch has has changed the third item, performance should be restored when
that is fixed. Let's see...
You are receiving this mail because:
- You are watching all bug changes.