cmder is extremely slow

[arieljannai]

Hi,

Cmder is very slow (I don't know if it's only me or not, I guess not).

• It takes about 6 seconds to open a new tab (cmd/powershell with the injections)
• 1.5-2 seconds to get output after pressing enter (even if it was an empty command. just pressing enter)
• The thing that takes most of the time from what I've seen, is the process of what cmder.lua does. Without it it takes significant less time to do simple operations (still not speedy as regular cmd or cygwin, but reasonable).
• I didn't pass through the script to see what it does (except setting some settings) but another thing that happens is that when I press enter I can see the tab name changing to git.exe and going back to cmd.exe afterwards. This process which I don't know yet why it's happening also slows it down a lot.

Hope those are things that can be fixed!

Please tell me if there's something I can check to help with that. It's a great tool and it's frustrating that I can't use it.

Thanks! ☀️
Ariel

If needed, I can record my screen while doing simple actions to demonstrate it 📹 💻

[kevinclcn]

It is same for me. That should caused by git. How can I disable the git prompt plugin?

[kevinclcn]

I just replace below line with return false to speed up.
https://github.com/cmderdev/cmder/blob/master/config/cmder.lua#L61

[arieljannai]

didn't helped 😢

[mynkow]

I also have extremely slow cmder but only when I connect trough remote desktop. The host machine is Windows 7 enterprise. KBD input takes 4-5 seconds per character. Opening cmder takes more than 6 seconds. All other console windows (cmd, bash, PS) are OK

How can I help to fix this?

PS: Probably this is the correct issue for my problem => #644

[youbiak]

Cmder is insanely slow for me too since the update !

[arieljannai]

on my personal computer (windows 10) it's extremely slow, but on my work computer (windows 7) it's pretty fine.

[arieljannai]

@Bliker any idea?

[ayoubfaouzi]

same here !

[luizbills]

+1

[okaufmann]

+1

[Manuzor]

Same here!

[MartiUK]

A lot of this is resolved in the CI builds, newer versions of completions in cmd and powershell are a lot faster.

I'm hoping to have a pre-release available soon.

[Manuzor]

@MartiUK: Awesome! Looking forward to it! 👍

[Bartimoot]

If it can help, running cmder as admin seems to solve the problem on my computer. (At least it isn't as slow..)

[superzadeh]

+1, same issue. It does not happens 100% of times though, sometimes restarting cmder fixes the problem.

[tribet84]

+1

[enriquein]

This happens to me usually when I launch cmder with a split panel configuration. Most of the times one of the panels will be fine and the other would be really slow to react to input. Agree that it usually works itself out if I close cmder and try opening it again.

[flyingduck92]

+1

[TaylorHuston]

This happens to me intermittently as well. Cmder is great 90% of the time, but occasionally (eventually?) it slows down to an insane crawl. A reboot is always needed to fix it.

[SCLeoX]

No fair...... I get i7 process and 16GB memory with 0s cmd start up time......

It takes me more than 40 seconds to start cmder in a non git directory. I have no idea why it is soooooooo slow.

[gustavohenke]

As a hint for anyone here:
I took the latest v1.3.0-pre tag, and it's almost real time for me if compared to the previous v1.2.9 release (which used to take 5 seconds every command).

[daxgames]

I have been using 1.3.0 pre for a long time and every now and then vim freaks out and hogs 98% cpu. Only way to recover is to kill vim.exe. No idea why but I have not really tried to figure it out.

[arieljannai]

I tried a few more times to reinstall cmder, now I'm with 1.3 pre and it's pretty much fine compared to what I had before. On 1.2 I encountered the most slowness in git folders (not that others were fast..).

Anyway, I still think it can be better, the problem is that I don't know what affects the slowness of cmder, maybe it's some settings, another programs etc.

If you also have this problem, react with 👍 on the issue itself, that way not all of the participants will get notifications for every +1 comment!

[delscorcho]

Any word on this? Starting a new PowerShell cmd window takes nearly a minute. It's unusable.

[Stanzilla]

@delscorcho which version of cmder are you on?

[delscorcho]

1.2.9. It's a lot better with the 1.3.0 pre-release.

[centur]

I'd like to add small hint to this thread ( and it might be a good idea to add this to the vendor/profile.ps1)
My Posh startup time goes bad beyond imagination (1.3.0 pre with few Azure modules installed takes from 3 to 12 seconds per console start) and after some research I found that this advice from SO is still valid, even for v5. Crazy but fact, start time plummeted down to 1-2 seconds per console start (and profile.ps1 boot time for Powershell is 0.2 secs with posh-git disabled)

[sebastianpennino]

Thanks @SCLeoX If I start my cmder on a git folder the problem is solved (i'm using cmder v1.2.9)

[arieljannai]

@centur which of the answers there were useful for you?

[centur]

@arieljannai oh, I didn't realize I referenced to the question, not to the answer.

"Run NGEN on Posh binaries." is useful, I have it in my profile script for admin prompt.
I also double-checked and re-enabled scheduler for NGENing my assemblies.

[S1d0]

Also for me it works really - my version 1.3.11.843. It tooks ages to startup also moving from one dir to other take really long. Looking forward for solutions...

[1ycx]

I read somewhere(Google how to speed up WSL) Windows Defender affects the speeds of WSL very very much. You can get 5x speed on WSL I/O and other operations by disabling it. Maybe disabling it will also help Cmder.

[jpruiz114]

This ticket is closed but seems like this is still happening, at least for me it happens on a daily basis, super slow to open new tabs and to perform simple things such as an ls.

[fabfreitas]

I solve the problem. I just installed Linux and... problem solved!! :)

[therepo90]

Same here

[davidnero]

I'm seeing extreme slowness as well.

[davidreza]

Smae issue here on a high-end laptop; in 2019

[davidnero]

In my case, the slowness was caused by my laptop looking for my employer's domain when I was at home. It seems to be some kind of windows terribleness where the domain lookup has to timeout before cmder (or maybe the underlying msys?) can run anything.

I found a work-around here: http://bjg.io/guide/cygwin-ad/)

[MyrionSC]

Turning off Windows Defender helped a lot for me.

[doglex]

just remove those function calls , and hard code all env, since you know the very git_install location.
My demo, https://github.com/doglex/Light_Weapon/blob/master/cmder/vendor/init.bat

which is fast
0.5s in HDD
0.1s in SSD

[blowsie]

I disabled the git as mentioned in one of the comments, cmder still taking 16 seconds to load

[aleksandarbos]

having it integrated with vscode, switching from branch to branch or writing a simple commit message is suuuper slow, any ideas on how to solve this?

[chrisant996]

Possibly is caused by anti-malware. Do you use ESET? For example, ESET has been having performance problems lately with ConEmu. If so, you can probably confirm by turning off "Deep Behavioral Inspection" in ESET.

[aleksandarbos]

Possibly is caused by anti-malware. Do you use ESET? For example, ESET has been having performance problems lately with ConEmu. If so, you can probably confirm by turning off "Deep Behavioral Inspection" in ESET.

hey, thanks for the reply. nope, just use standard win 10, no any custom anti-virus software installed - it uses standard win10 protection.

[daxgames]

@aleksandarbos I assume you are using git? How big is the git repo? Is the speed consistent across all git repos?

Is this a fresh cmder install or have you updated an old install over the years? Try a fresh install.

@chrisant996 if the below is incorrect, please correct me:

Look in %cmder_root%\config\cmder_prompt_config.lua for the below:

-- OPTIONAL. If true then always ignore the cmder.status and cmder.cmdstatus git config settings and run the git prompt commands in the background. 
  -- default is false 
  -- NOTE: This only takes effect if using Clink v1.2.10 or higher. 
 prompt_overrideGitStatusOptIn = false

Set it to true.

[aleksandarbos]

big thanks @daxgames it's fixed!

prompt_overrideGitStatusOptIn = true did the trick.

i've noticed it's git related, each time for example if i'd start typing something in cmder, vs code would start refreshing git status.

repo size is moderate i guess.

i just recently downloaded new version hoping it will fix it, and i'm on Version 1.3.20.151.

[daxgames]

@aleksandarbos Glad to help

[chrisant996]

i just recently downloaded new version hoping it will fix it, and i'm on Version 1.3.20.151.

What version of Cmder were you using before?

v1.3.20 includes improvements that make the git prompt be updated completely in the background; there should be zero delay from git anymore.

[aleksandarbos]

i just recently downloaded new version hoping it will fix it, and i'm on Version 1.3.20.151.

What version of Cmder were you using before?

v1.3.20 includes improvements that make the git prompt be updated completely in the background; there should be zero delay from git anymore.

prev version was 1.3.18.1106. not sure why but i got rid of git delay only after setting prompt_overrideGitStatusOptIn = true.

[chrisant996]

prev version was 1.3.18.1106. not sure why but i got rid of git delay only after setting prompt_overrideGitStatusOptIn = true.

Setting that completely disables the git status in the prompt.

But you also upgraded to 1.3.20, and you no longer need to set that: 1.3.20 fixed the git slowness.

[daxgames]

@chrisant996 this is the description of that setting and why I recommended it to him

-- OPTIONAL. If true then always ignore the cmder.status and cmder.cmdstatus git config settings and run the git prompt commands in the background.

-- default is false

-- NOTE: This only takes effect if using Clink v1.2.10 or higher. 

[chrisant996]

@aleksandarbos was using v1.3.18. That doesn't know about prompt_overrideGitStatusOptIn. In v1.3.18 the prompt is slow because it runs git commands in the foreground and waits for them to complete.

Upgrading to v1.3.20 is mainly what fixed the slowness.

@daxgames I misremembered how that works. I looked it up, and here is how it works:

Once upgraded to v1.3.19 or v1.3.20, then prompt_overrideGitStatusOptIn = true can work around an issue where the git config command was still being run in the foreground, which could still add some delay between command prompts.

v1.3.21 (not yet released) fixes that by moving git config into the background as well.

In v1.3.21 and higher, setting prompt_overrideGitStatusOptIn = true will not reduce the delay between command prompts (there shouldn't be any delay anymore), but it can potentially make the status info get refreshed sooner after the new prompt is displayed, since it skips even the background git config calls.

[aleksandarbos]

@chrisant996 after some more testing, it seems to be only the issue with the integrated cmder instance within the vscode. it clearly waits for git status and that seems the issue causing the cmder to run slow. launching cmder in a separate window, everything works fine.

[chrisant996]

@chrisant996 after some more testing, it seems to be only the issue with the integrated cmder instance within the vscode. it clearly waits for git status and that seems the issue causing the cmder to run slow. launching cmder in a separate window, everything works fine.

@aleksandarbos can you clarify? Earlier you said after upgrading to Cmder 1.3.20 and setting the Lua variable, the slowness was gone.

• Are you saying that Cmder 1.3.20 is still slow, but only inside vscode?
• Or are saying Cmder 1.3.18 was only slow inside vscode, and with Cmder 1.3.20 the slowness is gone?

If you're saying Cmder 1.3.20 is slow in vscode, can you double check that vscode is using Cmder 1.3.20 and not an earlier version of Cmder?

Also, can you clarify specifically where the slowness occurs? Are you saying when you press Enter at a command prompt with no input in the integrated Cmder 1.3.20 shell inside vscode, there is a delay before the next prompt appears? That's confusing since 1.3.20 runs git in the background and doesn't wait for it.

I could easily see how 1.3.18 could be extra slow inside vscode, since vscode itself runs git status frequently, and running two git status currently can make one of them take an extra long time due to lock contention.

[aleksandarbos]

where cmder points to the same distribution in both vscode integrated and non-integrated case Version 1.3.20.151. it seemed like it worked faster after updating the config, but looks like something is still holding off. i've clipped gif, it took almost 2 min to execute what i was writing. note that i wrote the sentence and waited for the whole time just to print it out

[chrisant996]

@aleksandarbos Thank you for clarifying where you're seeing slowness. That is very different from the slowness we were talking about between prompts. You're experiencing slowness while typing input.

I've never heard of that before.

I can try to take a look. If you happen to have instructions for how to set up Cmder integrated inside vscode, can you share a link?

[aleksandarbos]

think this one should do, https://github.com/cmderdev/cmder/wiki/Seamless-VS-Code-Integration. this is my config:

"terminal.integrated.profiles.windows": {
    "Cmder": {
      "path": [
        "${env:windir}\\Sysnative\\cmd.exe",
        "${env:windir}\\System32\\cmd.exe"
      ],
      "env": { "CMDER_ROOT": "E:\\tools\\cmder" },
      "args": ["/K", "%CMDER_ROOT%\\vendor\\bin\\vscode_init.cmd"],
      "icon": "cmder"
    }
  },
  "terminal.integrated.defaultProfile.windows": "Cmder",
  "terminal.integrated.allowChords": false,
  "terminal.integrated.drawBoldTextInBrightColors": false,
  "terminal.integrated.experimentalLinkProvider": false,
  "terminal.integrated.rendererType": "auto",

think that i was trying to solve this issue before, it had something to do with "terminal.integrated.rendererType": "auto" but not quite sure.

[chrisant996]

@aleksandarbos The ...rendererType setting was replaced by terminal.integrated.gpuAcceleration. See here. Does changing the ...gpuAcceleration setting in vscode to "off" make a difference? Have you tried updating your video drivers?

Also, when using git outside vscode, how long does manually running git status take in that repo?

Is that repo publicly available? I.e. can I clone it so that I have a repo where git status is slow? None of the repos on my home machine take longer than 1 second to run git status.

[aleksandarbos]

looks like switching "terminal.integrated.gpuAcceleration": "off" made things way better in my case. big thanks for the help @chrisant996