Wireshark-bugs: [Wireshark-bugs] [Bug 9696] New: Display filter performance is not O(n)
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 24 Jan 2014 09:11:03 +0000
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 bugzilla-admin@wireshark.org
Reporter philipp+wireshark@marek.priv.at 

Build Information:
TShark 1.10.5 (SVNRev 54262 from /trunk-1.10)

Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> 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.