Wireshark-bugs: [Wireshark-bugs] [Bug 7527] New: Repeated filter operations are unnecessarily sl
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7527
Summary: Repeated filter operations are unnecessarily slow
Product: Wireshark
Version: 1.6.8
Platform: x86-64
OS/Version: Windows 7
Status: NEW
Severity: Enhancement
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: symmetricone@xxxxxxxxx
Build Information:
Version 1.6.8 (SVN Rev 42761 from /trunk-1.6)
Copyright 1998-2012 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, without libpcre, without
SMI, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.12.18, with
Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio V19-devel (built May
22 2012), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 21022
--
When analysing a capture file, it is common to apply a number of increasingly
specific filters to drill down to the packets of interest. It is also common to
switch back and forth multiple times between filters that specify different
sets in the same session.
In both of these cases, Wireshark is significantly less fast than it could be,
because it appears to have no memory of previously applied filters, and so it
applies each filter from scratch. I propose two optimisations to improve the
situation:
1) Cache the packet list for the last N filters that have been applied to an
open capture file.
This should make a massive improvement to the execution time of filters in long
sessions. Bonus points for a UI indication of which filters in the filter
history have been cached (could highlight the history entry in light green, for
example). More bonus points for making N configurable (I suspect that changing
N should also change the number of filters that are kept in the filter history
as well).
2) Be more clever with the application of filters.
In many cases the new filter is a strict subset of the old one, so if I've
filtered a 10GB file down to 10MB, it's painful to have to refilter the whole
file when drilling down further into that 10MB.
e.g. I may apply these filters: 'sip', 'sip and ip.addr=="1.2.3.4"', ...
Some simple logic can determine that the second filter is a strict subset of
the first, and so we can just search within the results that we've already got
in hand, rather than parsing the whole file again.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
