This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Midnight Commander is very slow when starting and changing directories

I'm using midnight commander with Cygwin 64 bit on Windows 10 64 bit.

After moving to a new machine and a clean reinstall of windows and
cygwin, my midnight commander started to get very laggy - starting mc,
any change of directory or exiting from finding files (to refresh list
of files in the two panes) takes long seconds. Restarting doesn't

I have no idea what could be the reason for these hiccups. MC normally
works fine: arrow presses work well, viewing and editing is instant,
but this one thing takes up to 10 seconds - changing directories.
Searching in files has a similar lag, but only once (ie not in every
`chdir` it could have done). In non-mc cygwin usage this issue doesn't

The task manager doesn't show any abnormally high CPU or memory usage
on any process. I have `cygserver` running, using `bash` as my shell
and have no fancy `PS1` settings, my `$CYGWIN` is only

My environment:
* Windows 10 pro 64 bit, up to date
* Not connected to a domain, no network drives
* No anti virus software apart from the one built in Windows
* Two hard drives (system on SSD (C:), D: is a SSHD), quite a few
directory junctions from C: to C:, no loops
* I'm usually using fatty as the terminal, but mintty has the same issues
* GNU Midnight Commander 4.8.17
* cygserver is installed

Here is a strace log, maybe someone has an idea what did go wrong?
(recorded with `LOCALE=C strace -q -o /tmp/mc-log mc /tmp`)

In the recorded session I have:

* started mc in `/tmp` directory
* entered `/tmp/NVIDIA Corporation` directory
* went back up (`..`)
* entered `/tmp/mc-chanibal` directory
* went back up (`..`)
* exited with F10

You can see that normalize_posix_path  takes a lot of time, but trying
to force the same call with cygpath fails to take so long (more

Additional timing information:

A find of all directories in my `$HOME` takes 4.6 seconds:

    $ time find ~ -type d | wc -l
    (snipped two directories without permissions)

    real    0m4.626s
    user    0m0.796s
    sys     0m3.765s

A `ls -al` on all of these 19919 directories took a lot of time, but
the average was fairly low:

    time (find ~ -type d | while read f; do { time ls -al $f; } \
       |& awk '$1 == "real" { printf $2 }'                      \
       | awk -Fm '{printf( "%2.4f", $1 * 60 + $2 )}';           \
       echo -e "\t$f"; done                                     \
    ) >/tmp/ls-time-log ;
    (snipped two dirs without permissions)

    real    12m21.870s
    user    7m4.576s
    sys     16m34.446s

The average time to do an `ls -al` is 0.020s, min is 0.017, max is 0.154:

    $ awk 'BEGIN { sum=0; min=9999; max=0;  minf=""; maxf=""; }     \
          $1 { sum += $1;                                           \
               if(min > $1) { min = $1; minf = $2; };               \
               if(max < $1) { max = $1; maxf = $2; } }              \
          END { print "avg: " sum/NR; print "min: " min " "         \
              minf; print "max: " max " " maxf }' </tmp/ls-time-log
    avg: 0.0204292
    min: 0.0170 /cygdrive/c/Users/chanibal/AppData/Roaming/OculusClient/Local
    max: 0.1540

With the overhead of measuring time it averages 16m34s/19919 = 0.499s
per call to `ls -al`, two `awk`s and a iteration of `find`. Not very
good, but not four seconds.

Normalizing with `cygpath` doesn't take long:

    $ time strace cygpath -aw /tmp/NVIDIA\ Corporation/ | grep
      116   11175 [main] cygpath 3524 normalize_posix_path: src
/tmp/NVIDIA Corporation/
       20   11195 [main] cygpath 3524 normalize_posix_path:
/tmp/NVIDIA Corporation/ = normalize_posix_path (/tmp/NVIDIA

    real    0m0.034s
    user    0m0.015s
    sys     0m0.000s

I have also posted this issue to Super User, but after some discussion
with user Matzeri, he suggested for me to go on this list with this
problem. SU link:

-- KB

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]