Hi,
> all improvements are planned for 2.4
No problem for me.
Here’s some timing info if someone is interested.
15:02:49 Main Info set_console_log_handler, elapsed time 247000 us
15:02:49 Main Info Calling epan init, elapsed time 275000 us
15:02:50 Main Info epan done, elapsed time 1242000 us
15:02:50 Main Info Register all tap listeners, elapsed time 1253000 us
15:02:50 Main Info Calling extcap_register_preferences, elapsed time 1254000
us
15:02:51 Capture Dbg Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\androiddump.exe
15:02:52 Capture Dbg Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\ciscodump.exe
15:02:52 Capture Dbg Extcap [(null)]
15:02:52 Capture Dbg Interface [cisco] "Cisco remote capture"
15:02:52 Capture Dbg Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\randpktdump.exe
15:02:52 Capture Dbg Extcap [(null)]
15:02:52 Capture Dbg Interface [randpkt] "Random packet generator"
15:02:52 Capture Dbg Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\sshdump.exe
15:02:52 Capture Dbg Extcap [(null)]
15:02:52 Capture Dbg Interface [ssh] "SSH remote capture"
15:02:52 Capture Dbg Extcap pipe C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap\udpdump.exe
15:02:52 Capture Dbg Extcap [(null)]
15:02:52 Capture Dbg Interface [udpdump] "UDP Listener remote capture"
15:02:52 Capture Dbg Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52 Capture Dbg Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52 Capture Dbg Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52 Capture Dbg Extcap path C:\Development\wsbuild-gpl\run\RelWithDebInfo
\extcap
15:02:52 Main Info Calling module preferences, elapsed time 3004000 us
15:02:52 Main Info Calling fill_in_local_interfaces, elapsed time 3200000 us
15:02:52 Main Info fill_in_local_interfaces() starts
15:02:52 Capture Info sync_pipe_run_command() starts
15:02:53 Capture Info sync_pipe_run_command() ends, taking 0.229s, result=0
15:02:54 Capture Info sync_pipe_run_command() starts
15:02:54 Capture Info sync_pipe_run_command() ends, taking 0.163s, result=0
15:02:54 Capture Info sync_pipe_run_command() starts
15:02:54 Capture Info sync_pipe_run_command() ends, taking 0.173s, result=0
15:02:54 Capture Info sync_pipe_run_command() starts
15:02:54 Capture Info sync_pipe_run_command() ends, taking 0.164s, result=0
15:02:55 Main Info fill_in_local_interfaces() ends, taking 2.404s
15:02:55 Main Info Calling prefs_apply_all, elapsed time 5637000 us
15:02:55 Main Info Wireshark is up and ready to go, elapsed time 5952000us
Regards
Anders
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx]
On Behalf Of Roland Knall
Sent: den 4 januari 2017 09:53
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Subject: Re: [Wireshark-dev] extcap slowing down start of WS
@Stiq - this is the plan going forward. But first, I need to fix the initial call to the interfaces on Windows, because there is an issue with stdin buffers on Windows and a large number of interfaces.
The register preferences call is a necessity, but the one in fill_in_local_interfaces could be avoided, and should be actually. I'll look into that as well. But for now, all improvements are planned for 2.4, not 2.2
On Wed, Jan 4, 2017 at 8:20 AM, Stig Bjørlykke <stig@xxxxxxxxxxxxx> wrote:
On Tue, Jan 3, 2017 at 5:56 PM, Anders Broman
<anders.broman@xxxxxxxxxxxx> wrote:
> It now seems like extcap_register_preferences is the thing taking the
> longest time when starting up Wireshark, at least on Window.
One issue is that extcap_register_preferences is called before loading
the interfaces, and therefore all extcap binaries are run twice
because of multiple calls to extcap_reload_interface_list(). One in
extcap_register_preferences() and one in fill_in_local_interfaces().
This should be improved.
Loading extcap could be done in the background after Wireshark has
started, like is done in "Refresh Interfaces".
--
Stig Bjørlykke
