Cmder: Slow on startup

[lamarqua]

On my machine, a vanilla installation of Cmder takes >5s to startup compared to the instantaneous ConEmu.
I tried disabling everything in the init.bat script but it didn't really make a difference.

[daxgames]

If you disable everything in init.bat why use cmder then? Cmder is a set of tools including ConEmu that together is an enhanced version of the windows cmd shell and the init.bat is what handles loading those enhancements.

First time launch is slower because some cfg files are initialized. Launch will always be SLIGHTLY slower because it is not vanilla cmd.exe but should not be impactful. Second launch on my system takes under a second.

[lamarqua]

If you disable everything in init.bat why use cmder then? Cmder is a set of tools including ConEmu that together is an enhanced version of the windows cmd shell and the init.bat is what handles loading those enhancements.

I already know that, I am not stupid. I disabled it temporarily to see if that would make a difference on startup.

First time launch is slower because some cfg files are initialized. Launch will always be SLIGHTLY slower because it is not vanilla cmd.exe but should not be impactful. Second launch on my system takes under a second.

Not the case for me: it consistently takes ~5 seconds to launch. Once it is launched, creating a new cmd.exe shell (for example) in a tab or a window is quick.

Note that I am not talking about the first launch after installation, but every launch of a new instance of cmder.exe.

It strikes me as a serious performance problem, since the launcher doesn't need that long to do its job and defers to ConEmu for the rest, and ConEmu launches quickly on its own. I'm willing to help investigate it however I can.

[lamarqua]

Precisions: my machine is an Core 2 Duo E8400 running Win7 Family SP1. Cmder is installed on an SSD.

I'm gonna go ahead and see what I can understand on my own, but I'd appreciate any ideas about why this is so slow.

[kn0rki]

Hi,

maybe a virus scanner problem?
Try to look with procmon, whats going on when cmder.exe starts

Procmon

[lamarqua]

Found the problem:
https://github.com/cmderdev/cmder/blob/master/launcher/src/CmderLauncher.cpp#L172
The culprit "non-answering" process is akamai's netsession_win.exe. They don't offer it as stand-alone download - it's usually bundled with something else and I can't exactly remember what on my machine.
Unfortunately there's little we can do against netsession_win.exe being slow to process its messages (AFAIK the process does process the message, but very slowly - around 2.2 seconds per SendMessageTimeout. I don't know why). But there are different approaches to solving that problem:

1. Create the child ConEmu process _before_ the SendMessageTimeouts. The child process inherits the parent's Environment block (as per MSDN) so this works.
2. I'm not sure exactly why we need to broadcast an update everytime, even when no ConEmu window is open. So conditioning the SendMessageTimeout to the presence of a ConEmu top-level window could be one partial solution. (Using EnumWindow to list all top level windows.) Alas, the WM_SETTINGCHANGE message _has_ to be broadcasted in case of update per MSDN's documentation.
   2bis. Another solution would be to use SendMessageCallback which is asynchronous.
3. Lowering the timeout value. 5 seconds seems arbitrarily high, setting to a lower value could help cut away some of the wait.

I already implemented solution 1 (just rearranging the call to CreateProcess before the SendMessageTimeout) and it's much better for me. Please let me know if you want the pull request. I can also implement any other solution if necessary.

[luastoned]

Just updated Cmder today and I'm seeing the same issue. 5+ seconds on startup.

[Stanzilla]

@lamarqua yes, a PR would be great