Bug ID |
9696
|
Summary |
Display filter performance is not O(n)
|
Classification |
Unclassified
|
Product |
Wireshark
|
Version |
1.10.5
|
Hardware |
x86
|
OS |
Debian
|
Status |
UNCONFIRMED
|
Severity |
Major
|
Priority |
Low
|
Component |
Wireshark
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Build Information:
TShark 1.10.5 (SVNRev 54262 from /trunk-1.10)
Copyright 1998-2013 Gerald Combs <[email protected]> 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 GLib 2.36.4, with libpcap, with libz 1.2.8, with POSIX
capabilities (Linux), without libnl, with SMI 0.4.8, with c-ares 1.10.0, with
Lua 5.2, without Python, with GnuTLS 2.12.23, with Gcrypt 1.5.3, with MIT
Kerberos, with GeoIP.
Running on Linux 3.11-2-amd64, with locale de_AT.UTF-8, with libpcap version
1.5.2, with libz 1.2.8.
Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz
Built using gcc 4.8.2.
--
When displaying a capture file with ~75k packets, and then choosing eg.
"Follow TCP stream" (which results in ~10 packets being displayed), the filter
progress box shows a non-linear behaviour - the first 15k packets are done
nearly immediately, to get to 30k takes a few seconds, 45k are done after ~15
seconds, and to complete the filtering I had to wait ~45 seconds.
The capture file is 190MB and is on a shmfs (so should be completely in RAM),
/proc/pid/status says
VmPeak: 974592 kB
VmSize: 974592 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 200912 kB
VmRSS: 200912 kB
VmData: 359644 kB
I'm not sure what the cause is - list append, array resizing for each packet,
or something like that?
I'd have expected to get O(n) performance - extrapolating from the first second
lets me think that the whole file should be processed in 4-5 seconds.
Might be related to (closed) bug 3335, although that is about generating an
endpoint list.
Thank you!
You are receiving this mail because:
- You are watching all bug changes.