[Bug] cmder loads very slowly under Windows

minstyle commented 1 year ago

Version Information

Cmder version: v1.3.21 (1.3.20.151)
Clink: v1.4.11
git: version 2.39.1.windows.1
ConEmu: 221218 [64] Stable

Operating system: Windows 10 Pro 22H2 (Build 19045.2486)

Cmder Edition

Cmder Full (with Git)

Description of the issue

Since the latest Windows 10 update 22H2, it takes 30 seconds or more for cmder to load. It also takes this long when creating new tab windows in cmder. The problem exists with different Windows 10 computers at different work spaces and locations (private, work and Home Office).

How to reproduce

No response

Additional context

No response

Checklist

[X] I have read the documentation.
[X] I have searched for similar issues and found none that describe my issue.
[X] I have reproduced the issue on the latest version of Cmder.
[X] I am certain my issues are not related to ConEmu, Clink, or other third-party tools that Cmder uses.

mpitz commented 1 year ago

Same here!

Cmder version: v1.3.21 (1.3.20.151)
Clink: v1.4.10.45c041
git: version 2.39.0.windows.1
ConEmu: 221218 [64] Stable

Operating system: Windows 11 Pro 22H2 (Build 22621.1105)

Lari0 commented 1 year ago

Hi, Same here , it takes 20 or more seconds with /f and close to 60 without /f . Also tried adding variable of git location , this improves startup for few seconds.

Elapsed Time: 0:0:22.87 (22.87s total)

Microsoft Windows [Version 10.0.19045.2251] - Windows 10 Pro 22H2 cmder 1.3.20.151

chrisant996 commented 1 year ago

I am using Cmder 1.3.21 Mini version, with Windows 10 Pro 22H2 19045.2486, and it takes about 2 seconds to start.

I have git for Windows installed, and Cmder finds it successfully.

daxgames commented 1 year ago

I can not duplicate this.

WickedSilver commented 1 year ago

I can not duplicate this.

Is there any thing we can do to help you to reproduce this?

mpitz commented 1 year ago

Don't know if it helps but starting Cmder I can see rotating cmd.exe and findstr.exe in the lower tab:

Happens on my Windows 10 Pro private PC and my Windows 11 Pro office PC. On the office PC the startup takes significant more time than on the Win 10 machine.

Win 10: 10 sec
Win 11: 30 sec

daxgames commented 1 year ago

@mpitz 10 seconds is too long. The difference between home and work pc does not surprise me at all. Work PCs are commonly reported as slower with Cmder.

mpitz commented 1 year ago

@daxgames maybe, but my work PCs has no extra firewall restrictions, I'am admin user. It's like a private PC.

daxgames commented 1 year ago

When I said I can not reproduce this I was in a hurry. The only Windows 10 I have tested on is version 10.0.19044 21H2.2486 and according to Windows Ulpdate is up to date.

I am running Windows 10 on a 8GB Virtualbox VM on an older I5 laptop with slow spindle HDD and even on this older system Cmder starts in 3.68 seconds.

I will try and find another system in my stack of old hardware and see what I have to try and reproduce but if I can't get the version you guys say the issue started at I'm not sure what to do.

daxgames commented 1 year ago

@mpitz I'm just telling you historical experience. It comes up a lot.

js-compilatrum commented 1 year ago

Version mini and full at Microsoft Windows [Version 10.0.22621.1105] is very slow. It was checked on 128 GB RAM, 13700 CPU so hardware should will not be issue here. Older version on laptop is extremaly fast in comparision.

chrisant996 commented 1 year ago

Here are some ideas to try, to learn more about where the delay is coming from:

Try using Task Manager or Process Explorer to observe what processes are using CPU during the 10-30 second delay. For example, it might show that some antivirus system is spending a lot of CPU.
Try set PATH to check what the system path looks like. For example, if it has UNC paths in the system PATH then that will make network calls when searching to find executables, and that could introduce delays. Or there might be extra unexpected paths in the PATH that might slow things down.

Dzoukr commented 1 year ago

Don't know if it helps but starting Cmder I can see rotating cmd.exe and findstr.exe in the lower tab:

Happens on my Windows 10 Pro private PC and my Windows 11 Pro office PC. On the office PC the startup takes significant more time than on the Win 10 machine.

Win 10: 10 sec

Win 11: 30 sec

Absolutely the same here for me on Win 10 with cmder mini. I also tried to observe Task manager, but nothing significant there... Any idea what could cause it?

chrisant996 commented 1 year ago

What does set PATH report? For this, please copy/paste the actual text, not a screenshot (screenshots are images, so the text is not accessible, and trying to transcribe it into actual text is a time-consuming and error-prone process).

I ask because I see multiple findstr calls in the .bat and .cmd scripts that are part of Cmder, and many of them involve trying to analyze the %PATH% variable. It could potentially be possible for certain content in the %PATH% to lead to various problems, so examining the %PATH% can be a constructive diagnostic step.

andrej-dyck commented 1 year ago

Same. I extracted cmder.zip on a fresh install of Win10 22H2, and it takes up to 50sec to start.

daxgames commented 1 year ago

Found a system and got Windows 10 22H2 installed.
Downloaded Cmder Full 1.3.21 from the cmder.app web site.
- The version file in the archive says it is 1.3.20.151 and not 1.3.21. See #2818.
I unziped and ran cmder.exe.
- Launch speed seemed normal to me for a first launch.
- Git for windows did its initial install thing.
I added /t to the cmd::Cmder task, saved and relaunched. Had to do this twice for some reason???
Cmder started in less than 2 seconds.
Hardware is an older Intel i7 with 512Gb SSD and 16 GB RAM.

I cannot reproduce this issue.

I would love to see the output of path commands as requested above.

andrej-dyck commented 1 year ago

Here's some debug-output:

DEBUG(init.bat): Env Var - CMDER_ROOT=C:\<redacted-path>\Cmder

DEBUG(init.bat): Env Var - debug_output=1

DEBUG(init.bat): Looking for Git install root...

DEBUG(:read_version): Env Var - git_executable=C:\<redacted-path>\Cmder\vendor\git-for-windows\cmd\git.exe

DEBUG(:read_version): Env Var - GIT_VERSION_VENDORED=2.39.0.windows.1

DEBUG(:validate_version): ARGV[1]=VENDORED, ARGV[2]=2.39.0.windows.1

DEBUG(:parse_version): ARGV[1]=VENDORED, ARGV[2]=2.39.0.windows.1

DEBUG(:validate_version): Found Git Version for VENDORED: 2.39.0.windows.1

DEBUG(:read_version): Env Var - git_executable=C:\<redacted-path>\git-2.39.0\cmd\git.exe

DEBUG(:read_version): Env Var - GIT_VERSION_USER=2.39.0.windows.2

DEBUG(:get_user_git_version): get_user_git_version GIT_VERSION_USER: 2.39.0.windows.2

DEBUG(:validate_version): ARGV[1]=USER, ARGV[2]=2.39.0.windows.2

DEBUG(:parse_version): ARGV[1]=USER, ARGV[2]=2.39.0.windows.2

DEBUG(:validate_version): Found Git Version for USER: 2.39.0.windows.2

DEBUG(:compare_versions): Comparing:

DEBUG(:compare_versions): USER: 2.39.0.windows.2

DEBUG(:compare_versions): VENDORED: 2.39.0.windows.1

DEBUG(:compare_git_versions): campare versions_result: 1

DEBUG(init.bat): Using found Git '2.39.0.windows.2' from 'C:\<redacted-path>\git-2.39.0...

DEBUG(init.bat): Using Git from 'C:\<redacted-path>\git-2.39.0...

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\git-2.39.0\\cmd - found=1

DEBUG(:enhance_path): Env Var BEGIN PATH C:\\<redacted-path>\\git-2.39.0\\cmd - found=1

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\git-2.39.0\\mingw64\\bin - found=1

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\git-2.39.0\\mingw64\\bin - found=1

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\git-2.39.0\\usr\\bin - found=1

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\git-2.39.0\\usr\\bin - found=1

DEBUG(init.bat): Env Var - GIT_INSTALL_ROOT=C:\<redacted-path>\git-2.39.0

DEBUG(init.bat): Found Git in: 'C:\<redacted-path>\git-2.39.0'

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\Cmder\\vendor\\bin - found=0

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\Cmder\\vendor\\bin - found=0

DEBUG(:enhance_path): Appending 'C:\<redacted-path>\Cmder\vendor\bin'

DEBUG(:enhance_path): END Env Var - PATH=C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu\Scripts;C:\<redacted-path>\Cmder\vendor\conemu-maximus5;C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\dotnet\;C:\Program Files\Docker\Docker\resources\bin;;C:\<redacted-path>\git-2.39.0\bin;C:\<redacted-path>\git-2.39.0\cmd;C:\<redacted-path>\git-2.39.0\mingw64\bin;C:\<redacted-path>\git-2.39.0\usr\bin;C:\<redacted-path>\Gradle\gradle-7.6\bin;C:\<redacted-path>\Haskell\ghc-8.10.4\bin;C:\<redacted-path>\Java\jdk-17.0.2\bin;C:\<redacted-path>\JetBrains\scripts;C:\<redacted-path>\Kubernetes\bin;C:\<redacted-path>\Make\bin;C:\<redacted-path>\Maven\apache-maven-3.6.3\bin;C:\<redacted-path>\Node\node-18.13.0;C:\<redacted-path>\PHP\php-8.1.3;C:\<redacted-path>\PHP\composer;C:\<redacted-path>\Python\python-3.8.1;C:\<redacted-path>\Terraform;;C:\Users\<redacted>\AppData\Local\Microsoft\WindowsApps;C:\Users\<redacted>\.dotnet\tools;C:\<redacted-path>\Cmder\vendor\bin

DEBUG(:enhance_path): Env Var C:\\<redacted-path>\\Cmder\\vendor\\bin - found=1

DEBUG(:enhance_path_recursive): Env Var - add_path=

DEBUG(:enhance_path_recursive): Env Var - position=append

DEBUG(:enhance_path_recursive): Env Var - depth=0

DEBUG(:enhance_path_recursive): Env Var - max_depth=1

DEBUG(:enhance_path): Env Var INSIDE PATH C:\\<redacted-path>\\Cmder - found=0

DEBUG(:enhance_path): Env Var END PATH C:\\<redacted-path>\\Cmder - found=0

DEBUG(:enhance_path): Appending 'C:\<redacted-path>\Cmder'

DEBUG(:enhance_path): END Env Var - PATH=C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu\Scripts;C:\<redacted-path>\Cmder\vendor\conemu-maximus5;C:\<redacted-path>\Cmder\vendor\conemu-maximus5\ConEmu;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\Intel\WiFi\bin\;C:\Program Files\Common Files\Intel\WirelessCommon\;C:\Program Files\dotnet\;C:\Program Files\Docker\Docker\resources\bin;;C:\<redacted-path>\git-2.39.0\bin;C:\<redacted-path>\git-2.39.0\cmd;C:\<redacted-path>\git-2.39.0\mingw64\bin;C:\<redacted-path>\git-2.39.0\usr\bin;C:\<redacted-path>\Gradle\gradle-7.6\bin;C:\<redacted-path>\Haskell\ghc-8.10.4\bin;C:\<redacted-path>\Java\jdk-17.0.2\bin;C:\<redacted-path>\JetBrains\scripts;C:\<redacted-path>\Kubernetes\bin;C:\<redacted-path>\Make\bin;C:\<redacted-path>\Maven\apache-maven-3.6.3\bin;C:\<redacted-path>\Node\node-18.13.0;C:\<redacted-path>\PHP\php-8.1.3;C:\<redacted-path>\PHP\composer;C:\<redacted-path>\Python\python-3.8.1;C:\<redacted-path>\Terraform;;C:\Users\<redacted>\AppData\Local\Microsoft\WindowsApps;C:\Users\<redacted>\.dotnet\tools;C:\<redacted-path>\Cmder\vendor\bin;C:\<redacted-path>\Cmder

DEBUG(:enhance_path): Env Var C:\\<redacted-path>\\Cmder - found=1

DEBUG(init.bat): Env Var - HOME=C:\Users\<redacted>

DEBUG(init.bat): Calling - C:\<redacted-path>\Cmder\config\user_profile.cmd

Elapsed Time: 0:0:45.32 (45.32s total)

andrej-dyck commented 1 year ago

Note that this behavior I had first experiened on Windows 10 22H1 when I updated Cmder from an older version. I don't know which version I had before, but with that, the startup-time was 1-2sec.

d4k0 commented 1 year ago

Same problem here when I started Cmder today after I haven't used it for 2-3 weeks:

2023-01-22_19-49-34

Output of set PATH:

Path=E:\Tools\Cmder\vendor\git-for-windows\cmd;E:\Tools\Cmder\vendor\conemu-maximus5\ConEmu\Scripts;E:\Tools\Cmder\vendor\conemu-maximus5;E:\Tools\Cmder\vendor\conemu-maximus5\ConEmu;C:\Program Files\Java\jdk1.8.0_361\bin;C:\Program Files\Common Files\Oracle\Java\javapath;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;E:\Tools\Alacritty;E:\Tools\apache-ant-1.10.5\bin;C:\Users\*MyUsername*\AppData\Local\bin\NASM;D:\Program Files\CMake\bin;E:\Programme\Video\Konvertieren\FFmpeg;E:\Programme\Dokumente\AtomPortable\Tools\Node.js;E:\Tools\Cmder\vendor\git-for-windows\usr\bin;E:\Tools\Cmder\vendor\git-for-windows\bin;E:\Tools\Cmder;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files\Crucial\Crucial Storage Executive;C:\Program Files\dotnet\;C:\Program Files\gs\gs9.56.1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Users\*MyUsername*\.cargo\bin;E:\Program Files\Python\Python37\Scripts\;E:\Program Files\Python\Python37\;C:\Users\*MyUsername*\AppData\Local\Microsoft\WindowsApps;E:\Tools\Cmder\vendor\git-for-windows\mingw64\bin;E:\Tools\Cmder\vendor\bin
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
path_position=append

chrisant996 commented 1 year ago

@d4k0 While this probably isn't responsible for the delay, that PATH variable has several duplicates:

3 copies of c:\windows
3 copies of c:\windows\system32
2 copies of c:\windows\system32\openssh
3 copies of c:\windows\system32\wbem
3 copies of c:\windows\system32\windowspowershell\v1.0

Repeated directories can slow down launching programs, by searching the directories multiple times. Cleaning up the variable might be generally useful, but the duplicate directories probably aren't causing 40 seconds of slowdown, so the cause is probably something else yet to be discovered.

In the meantime, if you clean that up, make a backup copy of the contents of the PATH variable first, so that it can be restored if something goes wrong while cleaning it up.

chrisant996 commented 1 year ago

Can someone try downgrading to an older version of Cmder or ConEmu, and see if the problem goes away?

If downgrading ConEmu resolves the problem, then the issue is likely something in ConEmu, not Cmder.

If downgrading ConEmu doesn't resolve the problem, but downgrading Cmder resolves the problem, then there would be a possibility that the issue might be due to some recent change in the Cmder scripts.

andrej-dyck commented 1 year ago

I'll try it tomorrow. 👍

chrisant996 commented 1 year ago

@DRSDavidSoft @daxgames cmder init debug logging can show elapsed time of the whole init. Is there a way to see times along the way, to help identify where delays occur?

daxgames commented 1 year ago

@andrej-dyck is there really something in your path worth redacting?

andrej-dyck commented 1 year ago

@andrej-dyck is there really something in your path worth redacting?

Yes. But all paths only use the English letters and some use a space in-between words.

daxgames commented 1 year ago

@chrisant996 not currently

Hlsgs commented 1 year ago

@chrisant996 I have an older version of mini that i haven't updated in a while and that used to work fine(1.3.16.1035 with conemu 210912). Problem manifests same as with a freshly downloaded version.

@daxgames I've cleaned my path and that didn't help, so that's not it. I'm also unable to replicate this in a fresh VM with an up to date W10. Tricky. I was going to ask the same as @chrisant996 about a timestamped log file...

296951 commented 1 year ago

Looking at what it would take to add timestamps to the log.can't guarantee anything. My Bengals are playing and I am watching that. GO BENGALS - WOD-DEY!

296951 commented 1 year ago

@Hlsgs Slowness is USUALLY something on the host that is inspecting every API call, usually some Antivirus or Data Loss Prevention security tool. We see this mostly on corporate managed systems.

296951 commented 1 year ago

Has anyone tried using /f on the Conemu task?

296951 commented 1 year ago

Just added this to the main branch:

https://github.com/cmderdev/cmder/blob/6bd2e260f0892fcc895c5f67ba949e8597260823/vendor/lib/lib_console.cmd#L43

You can edit your local files and the a timestamped debug output.

d4k0 commented 1 year ago

@d4k0 While this probably isn't responsible for the delay, that PATH variable has several duplicates:

[...]

Thanks for the hint, I used "Rapid Environment Editor" to clean up the PATH variable (it has a function for this), but the loading time hasn't changed.

I also tried a fresh copy of Cmder mini, but it also loads very slowly (around 25s).

As @mpitz pointed out, Cmder is continuously switching between cmd.exe and findstr.exe.

The only thing that I installed lately was the latest Windows 10 22H2 update last week so this could maybe be the culprit. I will test Cmder on my work notebook tomorrow to see if I have this issue there as well.

daxgames commented 1 year ago

If you see cmder constantly doing findstr AND IT IS SLOW then put /f in your conemu task it'll skip trying to prevent duplication in the path and just modify the path.

It's not a fix but it is faster.

mpitz commented 1 year ago

@daxgames can you point out where to set the parameter exactly?

I've tryied to set it unter SETTINGS>STARTUP>TASKS>Task Parameters. But it says "unsupportet task parameters Task name : {cmd::Cmder} Parameters: /f

andrej-dyck commented 1 year ago

Do I undestand this correctly that /f doesn't search for git in PATH and uses the vendored 'git-for-windows'? If so, this means that the 'mini' version wouldn't have any git at all? Shouldn't it be the other way round (I didn't see another option) that says "don't do anything with my PATH"?

far3ki commented 1 year ago

Hi, Same here , it takes 20 or more seconds with /f and close to 60 without /f . Also tried adding variable of git location , this improves startup for few seconds.

Elapsed Time: 0:0:22.87 (22.87s total)

Microsoft Windows [Version 10.0.19045.2251] - Windows 10 Pro 22H2 cmder 1.3.20.151

also on my 2 computers the same, both Win11 Pro, 22H2, cmder 1.3.20.151

without /f - 47seconds,
with /f - 22seconds

I have tried the full version and also the mini version, changing/setting env variables, the same. I also think that this started after upgrade on 22H2 version.

andrej-dyck commented 1 year ago

I have a temporary solution for me.

I dug deep into the init.bat. I'm pretty sure I noticed some bugs and there's a lot of unnecessary work. In essence, I'm skipping almost everything and can reduce the start-up time from ~50sec to an acceptable 4.5sec.

Pre-requisites:

I'm currently on a Windows 10 22H2 machine
I have git installed and it's in path (%PATH_GIT%\bin, %PATH_GIT%\cmd, %PATH_GIT%\mingw64\bin, %PATH_GIT%\usr\bin)
I'm using the 'mini' version of Cmder
Make a backup ;)

Here are my changes (skipping mostly Git-related scripts):

Add set CMDER_CONFIGURED=2 to the top of the script (this jumps after some initial stuff directly to :USER_ALIASES)
Move :PATH_ENHANCE (l. 343) before first if "%CMDER_CONFIGURED%" GTR "1" (l. 215)
Move if "%CMDER_CONFIGURED%" gtr "1" goto :CMDER_CONFIGURED (l. 408) to start of :USER_CONFIG_START (l 346)

Note 1: referenced line numbers are those in the original file Note 2: move means delete the original line and paste it as it was to the new spot

Optional changes:

For :PATH_ENHANCE, replace enhance_path with set "PATH=%PATH%;%CMDER_ROOT%\vendor\bin" (s. screenshot above)
Skip %lib_base% update_legacy_aliases (l. 383) -- I have a clean install
Skip echo Migrating alias 'history' ... (l. 399 - 404) -- I have a clean install
Skip if exist "%GIT_INSTALL_ROOT%\post-install.bat" (l. 413 - 418) -- I use the 'mini' version and I'm pretty sure the placement is wrong here as it's only needed for vendored git

daxgames commented 1 year ago

@mpitz See below:

init.bat /f Does the following:

Reduces enhance_path to set path=... in that it does not do a findstr on the existing path to try and prevent adding things to the path that are already there.
Skips Git version detection.

@andrej-dyck Mini will always have git if it is in your path. [edit]

To avoid Git version detection, and the slowdown that comes with it, on Mini or Full set GIT_INSTALL_ROOT=[Git install path] env variable via Windows or use init.bat /f switch.

Be careful editing init.bat it is overwritten on every update of cmder.

Setting CMDER_CONFIGURED=2 skips:

Git version detection and configuration.
- This is slow
- Avoidable by setting GIT_INSTALL_ROOT=[Git install path] via Windows.
Add "%CMDER_ROOT%\vendor\bin" to the path configuration.
- Not super slow by itself, not as fast as it could be.
- Can be made faster by adding /f to the the Cmder task.
Add "%CMDER_ROOT%\bin" to the path configuration.
- Not super slow by itself, not as fast as it could be.
- Can be made faster by adding /f to the the Cmder task.
Running of user "%CMDER_ROOT%\config\profile.d" or "%CMDER_USER_CONFIG%\profile.d" scripts.
- If no scripts no delays.
- Delays are entirely user responsibility.
Other things but I need to dig deeper to identify them.

I would rather add an option for advanced users that would allow them to skip the included init.bat entirely and run their own in %cmder_root%\config\init.bat if the file exists. This would give users that want SUPER FAST and COMPLETELY customizable init while allowing Cmder still support the masses and be flexible.

I will also add an additional condition that only runs the post-install.bat if using vendored git. Not sure what good this will do because it should not exist in a pre-installed Git since it is run by the Git installer and deletes itself.

andrej-dyck commented 1 year ago

@daxgames thanks for the answer.

/f does nothing to git detection

In the 'full' version it does:

Mini will always have git if it is in your path but I think it still tries to do git detection which is unnecessary, If true I will fix,

Yes, it still tries to do some "vendored" Git stuff (:read_version, :validate_version, :compare_git_versions). So unnecassary in 'mini' and if you have Git in Path

Git version detection [skip] ... Avoidable by setting GIT_INSTALL_ROOT=[Git install path] via Windows.

Well, this reduced my init time from ~27sec to ~23sec. So there's still a lot that's worked on.

I would rather add an option for advanced users that would allow them to skip the included init.bat entirely and run their own [..]

We could do it right now, can't we?

andrej-dyck commented 1 year ago

@daxgames I noticed that within ConEmu / Cmder certain commands take a long time (~1sec compared to <50ms natively):

That doesn't explain all the unnecessary work in init.bat, though.

Update: I downloaded ConEmu and while it starts quickly, it also has the problem that some commands are executed very slow:

P.S. I wonder if this has something to do with WSL and that Windows 11 has a far better support for it. But on the other hand, I had cmder + wsl2 for more than 2 years (that I can remember) working well.

chrisant996 commented 1 year ago

Does the slowness happen with any Cmder versions prior to the current version?

If yes, then the cause is not really Cmder, it is something external such as an OS issue or antivirus issue or company-management software.

If stripping all scripts gets down to 4.5 seconds, that is still a very slow number, and should be more like 0.5 seconds.

So, it's starting to look like Cmder is just a victim of something external.

Detailed analysis and troubleshooting would be needed to performed by someone who is able to reproduce the issue.

I'm using Win10 22H2 with no change in Cmder startup, so I cannot repro and am unable to investigate at all.

daxgames commented 1 year ago

@andrej-dyck I realized the error in my statement regarding /f doing nothing for git detection and edited the original message shortly after I posted it.

We could do it right now, can't we?

I was thinking something a little more automatic. As in %cmder_root%\vendor\init.bat recognizes that %cmder_root%\config\cmder_init.bat exists and runs it else coutinue with the default %cmder_root%\vendor\init.bat

@chrisant996 I have been saying it is external all along. My Cmder startup speed varies wildly but is generally <2-3 seconds even with git version detection enabled. I have seen it as high as 14 Seconds after launching cmder.exe but the next launch could be 1-2 seconds.

I cannot reproduce the issue so I cannot offer a complete fix. There are some things that could be eliminated but these will not eliminate the delays reported here.

chrisant996 commented 1 year ago

@chrisant996 I have been saying it is external all along.

Yup. And I'm pretty sure it's external, as well.

The reason I continue to request/suggest additional info from users who are able to reproduce the issue is because being able to successfully demonstrate that it's external can help with redirecting the problem reports to an appropriate place that can do something about them. And in the unlikely event that additional info pinpoints that it is not an external issue, the addl info would help towards tracking down possible causes (e.g. maybe a batch script change with a non-obvious side effect that only malfunctions on machines with some certain system config).

daxgames commented 1 year ago

@andrej-dyck See below after some modifications, PR #2819, using Cmder Mini and User installed git with /f:

daxgames commented 1 year ago

@andrej-dyck

@daxgames I noticed that within ConEmu / Cmder certain commands take a long time (~1sec compared to <50ms natively)

We cannot control the speed at which commands run in Conemu.

daxgames commented 1 year ago

Unreleased build for #2819

https://ci.appveyor.com/project/cmderdev/cmder/build/artifacts

chrisant996 commented 1 year ago

Oh -- I might know what's happening ...

@andrej-dyck what does clink autorun show report?

If you installed Clink separately from Cmder and installed it for autorun, then every single launch of cmd.exe will also run clink inject. The first thing clink inject does is check if the target cmd.exe process is a non-interactive process, and if so then the inject is cancelled. But it still takes some time to do that.

It's one of the reasons I recommend to not set up Clink for autorun. There's nothing Clink can do to improve upon the autorun stuff -- that's completely up to cmd.exe. AutoRun is convenient, so that you don't have to make shortcuts to start cmd.exe with Clink, but unfortunately AutoRun can significantly slow down cmd.exe invocations. (If one isn't careful with what's put in the AutoRun regkey, it's even possible to create an infinite loop that consumes all CPU and memory launching thousands of cmd.exe processes reentrantly in a tight loop until the machine reboots -- and again, that's just how cmd.exe and AutoRun work, it's not part of Clink.)

On my machine, when Clink is configured for autorun, then Cmder takes 4 seconds to start, instead of 2 seconds.

Maybe some antivirus software is more aggressively interfering with Clink on your machine and making it slow. Normally it's very fast to do the inject short-circuit check, but Cmder's init.bat script uses many pipe operations, each of which launches a new hidden non-interactive copy of cmd.exe. (Even without anything in cmd.exe's AutoRun regkey, the pipes slow things down.)

So: if Clink is indeed configured for autorun, then try clink autorun uninstall, and see what kind of difference that makes on the speed.

But if Clink isn't configured for autorun, then I'm all out of ideas.

andrej-dyck commented 1 year ago

@daxgames First, good job with the PR#2819.

@daxgames @chrisant996 Yes, it's something external.

I don't think it has something to do with cmder or clink (as far as I can see, ConEmu doesn't come with clink out of the box) and I hadn't had clink installed (now, after this slowliness issue, I installed it and replaced cmder).

So I have Windows 10 22H2 (with 22H1 I experienced the same slowliness), some software (the big ?), and fresh zips of Cmder (mini) and ConEmu in different versions. All of them executed simple commands very slowly (s. https://github.com/cmderdev/cmder/issues/2816#issuecomment-1400530272). Given that Cmder has a large init.bat, it the slow commands accumulated.

My windows is not managed by any company (i.e., it's a personal Notebook). I turned off my antivirus software; still slow. I turned off any docker services; still slow. I have nothing in autostart, and suspicious services running (firefox updater, chrome updater, antivirus service [that I turned off temp.], lenovo platform service, nvidia).

Before my recent re-install of the complete system, all services and software for 2-3 years now and the Cmder slowliness appeared a couple of weeks ago. So, my best guess is, that it has something to do with Windows Updates?

andrej-dyck commented 1 year ago

@daxgames @chrisant996 Some more information.

While I was writing an response, I started up Windows Sandbox, extracted cmder_mini, and it starts in 2sec.

However, notice the older Windows 10 version in the sandbox!

Furthermore, on my company notebook, which is managed, has an aggressive antivir and most of the same software, Cmder is quite quick (1-2sec). There, I have Windows 11 installed.

chrisant996 commented 1 year ago

I'm curious specifically where the slowdown is coming from, even though it's external.

If someone can capture a performance trace using Windows Performance Recorder, I'd be willing to take a look and see if I can identify anything specific.

cmderdev / cmder