ls et al slow after updating cmder

[thomthom]

I had Win7 with cmder Version v1.1.4.1.

After updating to Win10 I noticed that cmder was out of date (due to the lambda not displaying correctly.)

I downloaded cmder from the website and now it says I'm running Version v1.2.9.

After doing this I notice that ls for instance often takes 20-30 seconds to return any output. (3 folders, 3 files.)

If I run ls against right after then it's fast again. But give it a few minutes and it will again be slow.

Any ideas what causes that?

[Stanzilla]

Please try https://github.com/cmderdev/cmder/releases/tag/v1.3.0-pre

[thomthom]

Same thing.

It also displayed an dialog that a newer stable version was available:

I got the same thing when I downloaded from the website and installed. That time I updated. This time I skipped - to stay on that particular build mentioned in the previous post.

[thomthom]

Any more info I can add?

[Stanzilla]

Can you do a 100% new installation, not overwriting anything. Just download https://github.com/cmderdev/cmder/releases/tag/v1.3.0-pre cmder.zip/7z and put it in a new folder and run it. The update prompt will always happen, the question is if the prompt itself looks fine, the lambda etc.

[thomthom]

When I updated I removed the old version first - and ran from a fresh clean extracted version.

The prompt itself looks fine. The only thing is the intermittent slow-down.

[Stanzilla]

Can you do where ls and post the output, please?

[thomthom]

λ where ls
C:\Program Files\Git\usr\bin\ls.exe

[thomthom]

If I open a regular cmd from that dir and use ls I don't seem to experience any lag. Only from within cmder.

[Stanzilla]

Well that means you are using an external version of git and it's tools, can you check the version of it? git --version

[thomthom]

git version 2.7.0.windows.1

I actually didn't install this manually - it got installed by another software, maybe Visual Studio.

I would be fine having cmder use the version it bundle instead. There was going to be a ENV variable one could use, right? Has that made it into this latest version?

[Stanzilla]

Well we always prefer already installed Git versions, see https://github.com/cmderdev/cmder/blob/master/vendor/init.bat#L43 so you can either update your installation manually or uninstall it since you already have it with cmder.

[thomthom]

Updated to Git 2.9, again experience the lag. I'll try to force cmder to use the bundled version and see how that goes.

[thomthom]

I made cmder load the git version that ships with cmder - but also this experience this lag. Any ideas to what I can do to debug further?

[Stanzilla]

Did you also update the included git version of cmder?

[thomthom]

No - I only updated the stand-alone version. You want me to try to update the bundled version as well?

(I might try to restore the original version I had - just to see if this relate to going from Win7 to Win10 - or updating cmder.)

[Stanzilla]

Well actually, download this https://ci.appveyor.com/api/buildjobs/k9lhpgfxryqhpft7/artifacts/build/cmder.7z unpack it into a NEW folder and tell me if that is still slow.

[thomthom]

Extracted into a completely new folder where cmder have never been located at - still the intermittent slow-down.

[thomthom]

When I compare the old 1.1.x version it's fast. I never seem to see the intermittent slowness. I notice it has a folder named msysgit while 1.2.x+ have git-for-windows. Relevant?

[thomthom]

I did an experiment - copied the vendor/msysgit from cmder 1.1 to the new version. And edited init.bat to use that folder for git - and then the slow down goes away. So it appear that the git-for-windows version shipped with cmder 1.2 and later doesn't play nice with my machine. (At least when running inside of cmder.)

[Stanzilla]

That would be something to report over at https://github.com/git-for-windows/ then

[thomthom]

The strange thing is - if I open a cmd in that folder where ls.exe is - I am not able to see the slow down. It appear to be a combination of cmder and git-for-windows.

[lunyx]

I'm not sure if I had the same exact issue, but I experienced the same thing you described whenever I was connected to a remote VPN. Disconnecting from the VPN resolved the issue, but obviously that's not a viable solution.

What seems to be working for me now:

 mkpasswd -l -c > C:\cmder\vendor\git-for-windows\etc\passwd
 mkgroup -l -c > C:\cmder\vendor\git-for-windows\etc\group

Then, in C:\cmder\vendor\git-for-windows\etc\nsswitch.conf:

# Begin /etc/nsswitch.conf

passwd: files # db
group: files # db

db_enum: cache builtin

db_home: env windows cygwin desc
db_shell: env windows # cygwin desc
db_gecos: env # cygwin desc

# End /etc/nsswitch.conf

The change here was that I commented out the db portion under passwd (I think group had that there already). Now, everything seems to be running quickly again.

[daxgames]

@lunyx Trying this tonight when I get home. It is painfully slow on the vpn but fast in the office. Will let you know.

[zhuzhzh]

I met this issue as well. I tried @lunyx 's solution. It works.

Another solution is to download ls_for_windows from https://u-tools.com/download_prod.asp?download%5Fid=600&Agree=1. put ls.exe into c:\cmder\bin.
one small issue is that the output of "ls.exe -l" sometimes is not aligned very well

[glucas]

I was seeing very slow ls.exe times, and just modifying nsswitch.conf as @lunyx suggested seems to have fixed it. (I did not create the passwd and group files.)

[thomthom]

Tweaking nsswitch.conf did not affect the performance lag for me.

[xmeng1]

commented out the db portion under passwd works for me currently

[ghost]

Had the same problem on win7x64, commenting out 'db' for 'passwd: files' in nsswitch.conf did the trick, just as indicated above. I didn't have to run mkpasswd or mkgroup to see the improvement.

[Cppowboy]

lunyx's solution works perfectly.

[mahyar-osn]

Tried the solution suggested by @lunyx and it now works perfectly! Thanks!

[seba9999]

+1 @lunyx 's trick worked 👍