Extremely slow startup

[empz]

I've upgraded from version 1.3.6.678 to latest 1.3.11.843 and the startup is painfully slow. More than 5s.

I've even tried downloading a fresh copy of the mini release and put it into my C: drive (which is a Samsung 960 EVO) and it's the same.

Previous version loaded almost instantly.

[hed0n1st]

@eparizzi : are you a windows insider ? actually i have the same issue, and i actually wonder if its not related to windows itself... some of my programs accessible via right-click ( open with... ) are now pretty slow to launch ( eg. for IDEs or archives programs ). On the other side the cmd/powershell shift/right-click works pretty well.
Also i had activated the sandbox for windows defender, disabling it reduced the launchs...
( sorry for mistakes, english not primary )

[daxgames]

they are virtually the same for me:

[daxgames]

If I add /f to cmd::Cmder task 1.3.11is actually 1 second faster than1.3.6`

[SpeedySparrow]

@daxgames Could you provide a little more info on where exactly you put /f. I have tried several scenarios but all fail.

[daxgames]

@SpeedySparrow it's all In the README.md

[SpeedySparrow]

Thanks. It did improve my startup, not quite with your impressive results but still better.

[daxgames]

You can also do a /t and it will give you an exact time it takes to start. How long does it take?

[SpeedySparrow]

Aah, that's where you got that timer from:-). Well, my readings doesn't make much sense to me. 3 times with and without /f. Using Launchy but directly from C:\cmder seems to yield the same weird measures.

Without /f
Elapsed Time: 39:30:34.00 (142234.00s total)
Elapsed Time: 15:28:34.00 (55714.00s total)
Elapsed Time: 69:27:42.00 (250062.00s total)

With /f
Elapsed Time: 17:22:32.00 (62552.00s total)
Elapsed Time: 65:22:7.00 (235327.00s total)
Elapsed Time: 22:21:45.00 (80505.00s total)

[daxgames]

That is still crazy slow even with /f

[daxgames]

@SpeedySparrow do you have an antivirus/antimalware you can disable and try again. These could be slowing it down. If they are you might be able to exclude cmder from on access scans and get it back to full speed.

Just curious what hardware you running this on, processor, hdd type, and memory?

[daxgames]

Those times can't be right the fastest says it took 15+ minutes to start

[SpeedySparrow]

True, something must be wrong with the timings. In real time:-) it's more like 5-6 seconds. I am on a Lenovo T460s with:
Win10 - ver. 1511
i5-6300U @ 2.4 GHz
20 GB RAM
But is a corporate computer with all sorts of anti-virus and what have we that I can't disable. Guess I just have to live with it.

Still weird with the timings:-)

[daxgames]

@SpeedySparrow I personally know others with corporate laptops that have the similar complaints. Sorry not anything we can do about that.

[p1va]

I also noticed slowness on my corporate laptop but after disconnecting the network drives i saw a huge improvement in startup time when opening new bash consoles.
Hope it helps.

[GF-Huang]

Is this startup speed normal? I think it is very slow.

[daxgames]

@GF-Huang yes. If you want it to be faster but sacrifice some rarely used functionality you can add /f to the task launching your session.

[keyiflerolsun]

Is this startup speed normal? I think it is very slow.

startup > tasks > cmd > add arg /f

[GF-Huang]

Got it, thank you all.

[mvanwaaijen]

for me it was the GIT_INSTALL_ROOT environment setting that was missing. therefore the init.bat was taking a long time to discover where git.exe was installed. After setting GIT_INSTALL_ROOT in my environment settings, cmder starts a whole lot faster.

[AliF50]

For me, it takes almost 9 seconds to launch. I added the /f argument variable. Is there anything I can do to make it faster? Before I remember it was almost instantaneous.

Those are my specs and my hard drive is an SSD.

[fakaki]

for me it was the GIT_INSTALL_ROOT environment setting that was missing. therefore the init.bat was taking a long time to discover where git.exe was installed. After setting GIT_INSTALL_ROOT in my environment settings, cmder starts a whole lot faster.

The hint from mvanwaaijen really helped!
Before: Cmder Startup time used to be 9 seconds on a modern Windows 10 Notebook, i5, 16 GB, SSD,...
After adding GIT_INSTALL_ROOT environment variable (system): < 3 seconds!

[AliF50]

Thanks fakaki, I got similar results as well by doing that recommendation.

For anyone wondering how to do it, add the line underlined in red here.

[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

[daxgames]

@doglex that works great for a single person with a single set of settings if that person wants to maintain his own init.bat. I wish we could bw that lean it just will not work for the masses.

[alextenev]

@doglex that works great for a single person with a single set of settings if that person wants to maintain his own init.bat. I wish we could bw that lean it just will not work for the masses.

Is it possible to store these values after first run? and then change them if the need arises?

[DerDemystifier]

If you don't use Git Bash that often, you can skip the whole thing after you run CMDer for the first time.
Note: You can always just comment this line when you're using bash regularily.

[daxgames]

@DerDemystifier I don't think that means what you think it means. 😀

I do not believe that variable is used by Git bash at all.

What it is used for is to skip re-running parts of init.bat if you MANAUALLY rerun it and it was previously run for the current shell session.

Released Cmder versions MUST run the init.bat EVERY new shell else you do not get enhancements Cmder provides.

Unreleased Cmder mentioned in a PR #2825 makes init.bat a run once action, after that Cmder launches Cmd.exe sessions in less than a second.

It's probably an external bad actor causing the issue and not Cmder at all. See issue #2816 for details on why Cmder load may be slow.