Wireshark-dev: Re: [Wireshark-dev] Profiled dumpcap
From: Anders Broman <[email protected]>
Date: Thu, 8 May 2014 16:41:09 +0000

Need to catch my train J

In valgrind script:

        d) COMMAND=dumpcap

           COMMAND_ARGS="-i eth1 -a duration:10"

           VALID=1 ;;

In dumpcap.c

        } else {

#if defined(DEBUG_DUMPCAP) || defined(DEBUG_CHILD_DUMPCAP)


                  "Wrote a packet of length %d captured on interface %u.",

                   phdr->caplen, pcap_opts->interface_id);




            /* if the user told us to stop after x packets, do we already have enough? */

            if ((global_ld.packet_max > 0) && (global_ld.packet_count >= global_ld.packet_max)) {

                global_ld.go = FALSE;




==18560== Callgrind, a call-graph generating cache profiler

==18560== Copyright (C) 2002-2012, and GNU GPL'd, by Josef Weidendorfer et al.

==18560== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info

==18560== Command: /home/ericsson/wireshark/.libs/lt-dumpcap -i eth1 -a duration:10


==18560== For interactive control, run 'callgrind_control -h'.

Capturing on 'eth1'

File: /tmp/wireshark_pcapng_eth1_20140508183539_dgwcQ9

Packets captured: 2844

Packets received/dropped on interface 'eth1': 2844/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:4) (100.0%)


==18560== Events    : Ir

==18560== Collected : 4189109


==18560== I   refs:      4,189,109


From: [email protected] [mailto:[email protected]] On Behalf Of Anders Broman
Sent: den 8 maj 2014 18:32
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Profiled dumpcap



Yes I just started to look at this myself and was surprised to see g_log() one should have expected that if no log handler was connected there be no cost of the operation…




From: [email protected] [mailto:[email protected]] On Behalf Of Evan Huus
Sent: den 8 maj 2014 18:24
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Profiled dumpcap


I assume that there was no other output (no logging or anything)? On my reading of the dump, most of the time is spent manipulating strings due to logging from the g_log function. The main caller seems to be capture_loop_write_packet_cb, so removing the logging call at dumpcap.c:4051 might be worth trying.



On Thu, May 8, 2014 at 11:57 AM, Anders Broman <[email protected]> wrote:


In case someone is interested...


Capturing on 'eth1'

File: /tmp/wireshark_pcapng_eth1_20140508174557_h4aOLn

Packets captured: 2756

Packets received/dropped on interface 'eth1': 2756/0 (pcap:0/dumpcap:0/flushed:0/ps_ifdrop:0) (100.0%)


==16851== Events    : Ir

==16851== Collected : 10910499


==16851== I   refs:      10,910,499




Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe


Attachment: callgrind.out.18560.bz2
Description: callgrind.out.18560.bz2