> At the moment there is a timeout of 4s to allow androiddump to connect to ADB.
I should be fixed right now and timeout should be 10ms (aka non-blocking socket on Windows and <maybe> on Linux/FreeBSD). If it is no 10ms (no ADB daemon started), then there is only a need to do truly non-blocking socket also for Linux/etc. (follow Windows solution). Current solution works (for me) on Linux (Ubuntu and LFS). The question is why there is significant delay for Guy, but not for me. I use Linux+cmake (out of source) + run Wireshark(s) from, build directory. Dario, could you share your results for: $ adb kill-server $ time run/extcap/androiddump --extcap-interfaces My results: real 0m0.013s user 0m0.000s sys 0m0.001s > about .26 seconds for randpktcdump It seems that your OS is much more slower than me in case of loading programs. What is it? "strace -tt -v ./run/tshark -D" may show there reason for it. Is that true that g_dir_open() is call many times for all extcap captures? It may be slow on some file[/]systems. Maybe the problem is extcap architecture: "small" binaries that must be run. We can (?) change it to libraries (plugins) + one generic small application that use "plugin". Then it is possible to link or dlopen libraries by Wireshark, but still can run it as standalone apps. I think that can save significant loading time and multiplatform compatibility. In other words: ./genericExtcapTextUI --load=randpktdump --extcap-interfaces or ./wireshark # it dlopen("libextcap_randpkt.so") etc. 2017-03-27 22:33 GMT+02:00 Guy Harris <g...@alum.mit.edu>: > On Mar 27, 2017, at 1:14 PM, Guy Harris <g...@alum.mit.edu> wrote: > >> Currently, with that fix, I get results like >> >> $ time ./tshark -r /tmp/nothing.pcap >> >> real 0m1.407s >> user 0m0.312s >> sys 0m0.676s >> >> with the extcap directory in place and results like >> >> $ time ./tshark -r /tmp/nothing.pcap >> >> real 0m0.334s >> user 0m0.182s >> sys 0m0.146s >> >> with the extcap directory moved out of the way, so the extcap executables >> are taking some time to run, but it's better than wasting time trying to run >> androiddump.c or Makefile.am. > > And, if I move various extcap executables out of the way: > > $ time ./tshark -r /tmp/nothing.pcap # all executables > > real 0m1.484s > user 0m0.313s > sys 0m0.720s > > $ time ./tshark -r /tmp/nothing.pcap # after removing androiddump > > real 0m1.179s > user 0m0.287s > sys 0m0.588s > > $ time ./tshark -r /tmp/nothing.pcap # after removing ciscodump > > real 0m0.950s > user 0m0.254s > sys 0m0.491s > > $ time ./tshark -r /tmp/nothing.pcap # after removing randpktcdump > > real 0m0.688s > user 0m0.228s > sys 0m0.334s > > $ time ./tshark -r /tmp/nothing.pcap # after removing sshdump > > real 0m0.493s > user 0m0.198s > sys 0m0.235s > > $ time ./tshark -r /tmp/nothing.pcap # after removing udpdump > > real 0m0.335s > user 0m0.183s > sys 0m0.145s > > So that's about .3 seconds for androiddump, about .23 seconds for ciscodump, > about .26 seconds for randpktcdump, about .19 seconds for sshdump, and about > .16 seconds for usbdump. > > So none of them are individually out of the ordinary, but about 1.5 to 2.5 > seconds per program, with 5 programs, adds up. > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Michał Łabędzki ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe