6

Does it seem to anyone else that the Windows 7 command processor (CMD.EXE) is really slow starting up?

I ran this test from a command line (ntimer is a timing utility from the Windows server resource kit and you can just leave it out if you don't have it installed):

ntimer cmd /c for /l %a in (1,1,100) do @cmd /c rem

All it's doing is shelling out a new CMD.EXE 100 times. On my x64 Win7 base system that takes about 2.3 seconds to run. Running this is in an x86 Win7 virtual machine it takes about 5.6 seconds. Interestingly enough, in the VM using the old 16 bit command processor COMMAND.COM the same test takes less than 1 second.

Why so slow for CMD.EXE? I expected performance similar to what I saw with COMMAND.COM in the VM. The ratio of speeds for CMD.EXE between the raw machine and the VM seems reasonable, but the absolute speed is way slow. Anyone have any thoughts on this? Thanks!

I noticed this because I was doing a software build and the execution time went from 15 minutes in my old XP VM to 30 minutes in my new Win7 VM. The build process uses the GNUMAKE utility and does LOTS of shelling out to the command processor.

P.S. I asked this originally over on stackoverflow.com, but they suggested I go here.

Scott Bussinger
  • 1,801
  • 4
  • 24
  • 27
  • It doesn't really sound like a sound approach to have it start so many separate shell processes, but then I'm unfamiliar with gnumake for windows... – Oskar Duveborn Aug 11 '09 at 21:43
  • cmd processses on WIn 7/8 and Server 2008 are a real nightmare. Conhost starts slow, hangs, stalls, and the whole launch takes 10x the time of previous OS. – The Coordinator Mar 24 '15 at 20:37

3 Answers3

1

There seems to be a problem with installed keyboard layouts and cmd.exe (at least that's true for my vista machine and some of my colleagues).

Try to remove any additonal languages from "System Settings->Region and Language options->Keyboards & Languages->Change keyboards->Installed Services" (translated on the fly - YMMV).

That reduced cmd.exe startup for me from "very annoying" to "instant".

1

instead of using cmd.com, have you tried PowerShell? I believe it's under accessories.

Keith
  • 352
  • 3
  • 11
  • I haven't tested powershell because the real problem I was having was the speed of an existing software build process. The effort to convert it to powershell would far exceed the benefits. Let's face it, a process that forks thousands of command shells is a highly fringe case. I was just surprised at the huge difference in speed between COMMAND.COM and CMD.EXE and at how slow CMD.EXE really was at starting up. – Scott Bussinger Jun 16 '09 at 16:33
  • 1
    You could try starting up XP mode inside of Windows 7 and see if your performance is better there. – Keith Jun 16 '09 at 20:31
  • I'd been using VirtualBox, but testing under Windows Virtual PC (basically an updated version of Virtual PC 2007 and the underpinnings of XP Mode) was a good idea. The same test there took 3.1 seconds for CMD.EXE and 1.1 seconds for COMMAND.COM (as compared to 2.8 seconds and 1.5 seconds under VirtualBox -- close enough to the same speed). So, the XP COMMAND.COM times were about the same as under Win7, but the CMD.EXE times are almost double (and XP CMD.EXE already took 3 times longer than COMMAND.COM so the Win7 version is 6 times longer). – Scott Bussinger Jun 17 '09 at 07:12
  • powershell is ALSO really slow to load. – djangofan Nov 19 '09 at 19:20
  • PowerShell v2 loads pretty fast on my Win 7 machine. It's slow the first time, but once it's in memory it's fast. – Jay Bazuzi Feb 08 '10 at 16:55
0

I suggest to use Sysinternals Process Explorer and Process Monitor to get an idea what is going on while it hangs. There are a lot of great tutorials for both programs and I highly recommend to get familiar with them.

Christoph Schmidt
  • 56
  • 4