Comment # 8
on bug 11698
from Guy Harris
With:
Version 2.1.0 (v2.1.0rc0-524-g2d7b0fc from master)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.5.0, with libpcap, without POSIX capabilities, with
libz 1.2.5, with GLib 2.36.0, with SMI 0.4.8, with c-ares 1.10.0, with Lua 5.2,
with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with GeoIP, with
QtMultimedia, without AirPcap.
Running on Mac OS X 10.10.5, build 14F1021 (Darwin 14.5.0), with locale C, with
libpcap version 1.5.3 - Apple version 47, with libz 1.2.5, with GnuTLS 2.12.19,
with Gcrypt 1.5.0.
Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz (with SSE4.2)
Built using clang 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.1.76).
opening the file with a "display" filter of data.data[0] == 0x2b took 40.526
seconds, opening it with no "display" filter took 20.613 seconds, and
subsequently filtering it with a display filter of data.data[0] == 0x2b took
35.477 seconds.
After opening it with no "display" filter and subsequently filtering it with a
display filter of data.data[0] == 0x2b, clearing the filter took 26.418
seconds.
After opening the file with a "display" filter of data.data[0] == 0x2b,
clearing the filter took - oh, wait, I *can't* clear it!
That's why I put "display" in quotes - it's *not* a display filter, it's what
is called a "read filter", meaning that, when reading the file, packets that
don't match the filter are ignored, rather than being temporarily filtered out.
And, in fact, at least in a recent Windows build:
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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 Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8,
with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with
QtMultimedia,
with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, with
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap
version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2,
with
AirPcap 4.1.3 build 3348.
the dialog labels it as a "Read filter".
This means that there's a significant difference between the two operations.
If you read the file without a read filter, each packet in the file is added to
the list of packets and the display, and filtering it with a display filter
then re-reads all the packets, re-dissects them and re-runs the filter on them,
and adds the packets that match to the display. If you read the file with a
read filter, only packets that match the filter are added to the list of
packets and the display.
And re-filtering took *less* time than reading with a read filter (35.477
seconds vs. 40.526 seconds) on my machine and OS.
So one issue here is that we're mislabeling the filter in the open dialog - I
seem to remember some discussion of the renaming, but we should perhaps reopen
that discussion.
However, the "high speed for opening" image seems to indicate that a read
filter *wasn't* used in that example. When you say "open test.pcap with
display filter data.data[0] == 0x2b", do you mean that "data.data[0] == 0x2b"
was entered in the "Read filter" field in the Open dialog?
