My question is similar to
I think my problem is caused by a different issue though.
Here is an example of extremely slow commands in Cygwin:
time for i in {1..10} ; do bash -c "echo Hello" ; done
Hello
...
real 0m21.588s
user 0m0.458s
sys 0m0.989s
Something is causing this... but what could it be?
Things that I have tried:
C:\cygwin\bin
via windows CMD
, e.g. C:\cygwin\bin\ls.exe
, they are still slow.I then tried running this command to get a better idea of what's going on:
strace -o bash.strace bash -c "echo hello"
From what I can see there is one row that was taking 90% of the time:
(in case it's not clear it is the row starting with 1028210 - I included the other rows for context)
5 5 [main] bash 1088 open_shared: name shared.5, n 5, shared 0x60FB0000 (wanted 0x60FB0000), h 0x74C
208 213 [main] bash 1088 heap_init: heap base 0x530000, heap top 0x530000
118 331 [main] bash 1088 open_shared: name S-1-5-21-2025429265-1957994488-1801674531-1003.1, n 1, shared 0x60FC0000 (wanted 0x60FC0000), h 0x748
85 416 [main] bash 1088 user_info::create: opening user shared for 'S-1-5-21-2025429265-1957994488-1801674531-1003' at 0x60FC0000
83 499 [main] bash 1088 user_info::create: user shared version 6112AFB3
344 843 [main] bash 1088 dll_crt0_0: finished dll_crt0_0 initialization
283 1126 [main] bash 1088 _cygtls::remove: wait 0xFFFFFFFF
87 1213 [main] bash 1088 _cygtls::remove: removed 0x23CE64 element 0
104 1317 [main] bash 1088 _cygtls::remove: wait 0xFFFFFFFF
70 1387 [main] bash 1088 _cygtls::remove: removed 0x23CE64 element 0
102 1489 [main] bash 1088 _cygtls::remove: wait 0xFFFFFFFF
70 1559 [main] bash 1088 _cygtls::remove: removed 0x23CE64 element 0
110 1669 [main] bash 1088 _cygtls::remove: wait 0xFFFFFFFF
70 1739 [main] bash 1088 _cygtls::remove: removed 0x23CE64 element 0
781 2520 [main] bash 1088 _cygtls::remove: wait 0xFFFFFFFF
76 2596 [main] bash 1088 _cygtls::remove: removed 0x23CE64 element 0
278 2874 [sig] bash 1088 wait_sig: entering ReadFile loop, my_readsig 0x72C, my_sendsig 0x728
1028210 1031084 [main] bash 1088 mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Adam, no-keep-rel, no-add-slash)
107 1031191 [main] bash 1088 normalize_win32_path: C:\cygwin\home\Adam = normalize_win32_path (C:\cygwin\home\Adam)
59 1031250 [main] bash 1088 mount_info::conv_to_posix_path: /home/Adam = conv_to_posix_path (C:\cygwin\home\Adam)
11535 1042785 [main] bash 1088 _cygwin_istext_for_stdio: fd 0: not open
69 1042854 [main] bash 1088 _cygwin_istext_for_stdio: fd 1: not open
62 1042916 [main] bash 1088 _cygwin_istext_for_stdio: fd 2: not open
360 1043276 [main] bash (1088) open_shared: name cygpid.1088, n 1088, shared 0x60FE0000 (wanted 0x60FE0000), h 0x678
65 1043341 [main] bash 1088 **********************************************
46 1043387 [main] bash 1088 Program name: C:\cygwin\bin\bash.exe (pid 1088, ppid 1)
46 1043433 [main] bash 1088 App version: 1007.7, api: 0.230
45 1043478 [main] bash 1088 DLL version: 1007.9, api: 0.237
46 1043524 [main] bash 1088 DLL build: 2011-03-29 10:10
51 1043575 [main] bash 1088 OS version: Windows NT-5.1
45 1043620 [main] bash 1088 Heap size: 402653184
45 1043665 [main] bash 1088 **********************************************
45 1043710 [main] bash 1088 pinfo::thisproc: myself->dwProcessId 1088
50 1043760 [main] bash 1088 time: 1321506515 = time (0)
862 1044622 [main] bash 1088 parse_options: glob (called func)
78 1044700 [main] bash 1088 parse_options: returning
45 1044745 [main] bash 1088 environ_init: GetEnvironmentStrings returned 0x10000
...
I don't really understand what problem the offending line could be alluding to:
mount_info::conv_to_posix_path: conv_to_posix_path (C:\cygwin\home\Adam, no-keep-rel, no-add-slash)
How can I debug this issue further? Does anyone have any ideas?
Since updating to the latest Cygwin (v2.769), this is much less of an issue. (Previously I was using v2.738 I think)
Under 2.769, the same command gives much better results:
$ time for i in {1..10} ; do bash -c "echo Hello" ; done
Hello
...
real 0m0.641s
user 0m0.379s
sys 0m0.506s
Cygwin is still slower than I would like - I mainly use it for git and vim, and both of those are much slower than their native counterparts.
But it is at least much more usable now.