Quelqu'un d'autre a-t-il l'impression que le processeur de commande de Windows 7 (CMD.EXE) est vraiment lent à démarrer ?
J'ai effectué ce test à partir d'une ligne de commande (ntimer est un utilitaire de chronométrage du kit de ressources pour serveurs Windows et vous pouvez le laisser de côté si vous ne l'avez pas installé) :
ntimer cmd /c for /l %a in (1,1,100) do @cmd /c rem
Tout ce qu'il fait, c'est éjecter un nouveau CMD.EXE 100 fois. Sur mon système de base Win7 x64, cela prend environ 2,3 secondes pour s'exécuter. Si je l'exécute dans une machine virtuelle Win7 x86, cela prend environ 5,6 secondes. Il est intéressant de noter que dans la machine virtuelle utilisant l'ancien processeur de commande 16 bits COMMAND.COM, le même test prend moins d'une seconde.
Pourquoi CMD.EXE est-il si lent ? Je m'attendais à des performances similaires à celles que j'ai observées avec COMMAND.COM dans la VM. Le rapport des vitesses pour CMD.EXE entre la machine brute et la VM semble raisonnable, mais la vitesse absolue est très lente. Quelqu'un a-t-il des idées à ce sujet ? Merci !
J'ai remarqué cela parce que je faisais une construction de logiciel et le temps d'exécution est passé de 15 minutes dans mon ancienne VM XP à 30 minutes dans ma nouvelle VM Win7. Le processus de construction utilise l'utilitaire GNUMAKE et effectue BEAUCOUP d'éjection vers le processeur de commande.
P.S. J'ai posé cette question à l'origine sur stackoverflow.com, mais ils m'ont suggéré de la poser ici.
0 votes
Cela ne semble pas vraiment être une bonne approche de lui faire démarrer autant de processus Shell séparés, mais alors je ne suis pas familier avec gnumake pour Windows....
0 votes
Les processus cmd sur WIn 7/8 et Server 2008 sont un véritable cauchemar. Conhost démarre lentement, se bloque, s'arrête, et le lancement complet prend 10 fois plus de temps qu'avec le système d'exploitation précédent.