Pourquoi MinGW est très lent?

vous Êtes sur un domaine Active Directory, mais pas immédiatement connecté?

bien que je n'ai pas la "réponse" quant à la raison pour laquelle MinGW serait lent, il a été mon expérience que les ordinateurs qui appartiennent à un domaine publicitaire, mais sont incapables d'atteindre le contrôleur publicitaire, ont un retard dans le démarrage des exécutables (tels que rxvt.exe) et ceux qui tournent actuellement font l'expérience d'une pause ou d'un bégaiement (comme emacs, qui est construit en utilisant MinGW).

j'enquête toujours pour déterminer réel cause de ce comportement, mais j'ai pensé que je voudrais le mentionner au cas où il s'applique à vous.

beaucoup de choses "unixy" sur MinGW sont douloureusement lentes, parce que Windows n'a pas fork(). Windows uniquement a CreateProcess(), ce qui est très différent. Les shells Unix et GNU font beaucoup de bifurcation, donc les exécuter sous MinGW se traduit par des bifurcations" émulées", qui sont vraiment lentes.

une autre chose qui souffre de cela est GNU Autotools, donc en cours d'exécution ./configure scripts lors de la construction d'applications "unixy" à partir de sources est également très lent. Cela peut devenir vraiment ennuyeux si vous avez besoin de faire beaucoup temps (par exemple, quand avoir des problèmes avec obtenir configurer pour trouver toutes les bibliothèques).

Cette réponse explique plus en détail comment Cygwin et MinGW utilisé pour simuler fork() et cette réponse a plus d'explication.

MSYS 1.0.19-1, si le compte utilisateur est dans le domaine Active Directory et que le contrôleur de domaine (DC) est inaccessible, alors MSYS DLL va introduire un long délai avant de lancer tout exécutable MSYS (qui utilise MSYS DLL). Cela affecte MSYS make et tous les utilitaires en ligne de commande du paquet CoreUtils tels que ls,rm etc qui sont typiquement installés dans C:\MinGW\msys.0\bin.

Observations:

• lors du lancement des utilitaires à partir de MSYS bash shell, seul le démarrage de shell est touché par le retard. Les utilitaires lancés depuis le shell ne sont pas impact.

• Le délai peut varier, dans mon cas c'est 21sec.

• L'exécution d'un utilitaire MSYS dans les 10-20 sec après la commande retardée sera lancée sans Nouveau Délai.
• le problème se produit lorsque la machine est connectée à un réseau différent, ou lorsqu'elle est déconnectée de son domaine, ou lorsque le nom d'hôte du contrôleur de domaine change (problème dans mon cas.) Pour vérifier si DC est accessible, ouvrezcmd et tapez echo %LOGONSERVER%, puis ping ou net view avec le nom d'hôte du DC.

Pourquoi est-il si lent:

• le code de MSYS DLLuinfo.cc internal_getlogin() effectue deux appels système pour obtenir des renseignements sur les utilisateurs. Première fois qu'il appelle NetUserGetInfo() pour récupérer le compte utilisateur à partir de la machine locale. Il échoue pour les utilisateurs du domaine, donc il l'appelle pour la deuxième fois avec le serveur DC pris de LOGONSERVER variable. Si l'hôte n'est pas immédiatement accessible, il introduira un long délai jusqu'à ce que l'appel échoue sur timeout. La demande commencera peu après.

Comment éviter ce problème, plusieurs solutions:

• soit exécuter tout à partir de MSYS shell, ou
• si la raison est la modification de DC hostname, alors un redémarrage ou une nouvelle connexion résoudra le problème. Windows mettra à jour automatiquement LOGONSERVER avec le bon hôte DC.
• si les outils MSYS sont appelé à partir de Windows cmd ou un script, puis définissez LOGONSERVER localhost pour éviter l'accès au réseau. E. g. set LOGONSERVER=\LOCALHOST a travaillé pour moi. Note: cette variable est définie à l'ouverture de session et le changer globalement dans Windows environment Variables window n'a aucun effet comparé à le définir dans cmd ou un script.
• je considère que C'est un bug dans MinGW/MSYS. Le code dans MSYS2 et Cygwin est différent. J'ai vérifié MSYS2 et il n'y a pas de problème.

Vous pouvez essayer d'utiliser une version plus récente de l'ensemble d'outils. J'ai trouvé ceci pour être utile: http://nuwen.net/mingw.html Il dispose de tous les outils utilisés par MinGW et common APIs dans un seul gros paquet. Sur le site:

Mon MinGW de distribution ("distribution") est de 64 bits natif et contient actuellement GCC 6.1.0 et Boost 1.61.0.

MinGW est un port de GCC vers Windows. Il est gratuit et simple à utilisation (bien, aussi simple que toolchains jamais). Il produit autonome Les exécutables Windows qui peuvent être distribués de n'importe quelle manière.