Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 3335] New: Poor Performance Performance with Larger Capture Files

[bugzilla-daemon@xxxxxxxxxxxxx]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3335

           Summary: Poor Performance Performance with Larger Capture Files
           Product: Wireshark
           Version: 1.0.6
          Platform: Other
        OS/Version: Windows XP
            Status: NEW
          Severity: Normal
          Priority: Medium
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: bzikmund@xxxxxxxxx


Created an attachment (id=2863)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=2863)
Screen shots of slow performance

Build Information:
Version 1.0.6 (SVN Rev 27387)

Copyright 1998-2009 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 with GTK+ 2.12.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with ADNS, with Lua 5.1, with GnuTLS 2.6.3, with Gcrypt 1.4.3, with MIT
Kerberos, with PortAudio V19-devel, with AirPcap.

Running on Windows XP Service Pack 2, build 2600, without WinPcap, without
AirPcap.

Built using Microsoft Visual C++ 6.0 build 8804

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
I have noticed a disturbing trend with analysis of larger capture files
(>60000) packets.  Several functions appear to have exponential processing
times, greatly inhibiting the use of Wireshark for larger captures. These
routines should be using an indexed access method which yields a near linear
processing time, as opposed to the exponential times observed.  Not all
functions are affected, for example Statistics - Protocol Hierarchy appears to
process linearly while endpoints and conversations do not.  One other problem,
is that the STOP button has no effect when processing large files - you must
wait for the file to process no matter how many times you click STOP.

For example, performing a Statistics - Endpoints analysis of 60,000 frames
(w/170 endpoints) takes about 7 seconds on a lenovo T61 Intel Core 2 Duo (2
GHz) 2 GB DDR2 SDRAM.  Wireshark.exe ram usage is just under 40MB.  However,
with more frames, the processing rate falls off sharply, even though ram usage
is well under physical memory.  

frames endpointlisttime 
====== ================
60K 7sec  (Wireshark process Ram utilized ~40MB)
100K 15sec 
160K 37sec 
200K 90sec 
260K 140sec
280K 190sec
300K 220sec (Wireshark process Ram utilized ~180MB)
680K 15 minutes
780K 20 minutes
900K 30 minutes (Wireshark process Ram utilized ~750MB)

While I am not advocating that one should be processing 900K frame trace files,
the processing time should be a linearly proportional to trace file size and
not exponentially proportional.


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.