Dev Faq
7
votes

Git Diffotant ridiculement lent dans Cygwin / Mingw

J'ai remarqué que git diffotan code> est très lent. Un délai d'environ 1..2 secondes apparaît entre chaque invocation DIFF.

Pour repasser, j'ai écrit une commande personnalisée DIFFTOOL code> commande: p> xxx pré>

et configuré git pour utiliser cet outil dans mon ~ / .GITCONFIG CODE> P> 

| Cygwin | Debian | Ubuntu | Method   |
| ------ | ------ | ------ | -------- |
| 10.381 |  2.620 | 0.580  | difftool |
|  1.149 |  0.567 | 0.210  | custom   |

4 commentaires

Salut. Je suis confronté au même problème. Avez-vous déjà reçu une réponse sur laquelle Git Diftool est si lent?

Non, je n'ai pas encore trouvé de solution.

Salut. Je pensais que vous pourriez être intéressé par le fait que cette question ait été corrigée dans GIT 2.8.1 pour Windows. S'il vous plaît voir Github.com/git-for-windows/git/issues/711 < / a>.

Je vois exactement le même comportement dans Mingw64 avec Git 2.8.1. En outre, @Jeyoung le problème que vous avez lié est pour l'intégration VIM. Différent problème, peut-être?

3 Réponses :

2
votes

Utiliser certaines des techniques trouvées sur le MSYSGIT GITUB , j'ai réduit cela un peu.

pour chaque fichier dans le diff em>, git-diff totant - assistant code> réenregistre les commandes internes suivantes : P> 

12:44:46.941239 git.c:351               trace: built-in: git 'config' 'diff.tool'
12:44:47.359239 git.c:351               trace: built-in: git 'config' 'difftool.bc.cmd'
12:44:47.933239 git.c:351               trace: built-in: git 'config' '--bool' 'mergetool.prompt'
12:44:48.797239 git.c:351               trace: built-in: git 'config' '--bool' 'difftool.prompt'
12:44:49.696239 git.c:351               trace: built-in: git 'config' 'difftool.bc.cmd'
12:44:50.135239 git.c:351               trace: built-in: git 'config' 'difftool.bc.path'
12:44:50.422239 git.c:351               trace: built-in: git 'config' 'mergetool.bc.path'
12:44:51.060239 git.c:351               trace: built-in: git 'config' 'difftool.bc.cmd'
12:44:51.452239 git.c:351               trace: built-in: git 'config' 'difftool.bc.cmd'

0 commentaires
1
votes

git diffuttoques devrait être légèrement plus rapide avec GIT 2.13 (Q2 2017)
Voir COMMIT DE12A8CF (14 avril 2017) par Jeff Hostlertler ( Jeffhostler ) .
(fusionné par Junio ​​C Hamano - Gitster - dans COMMIT 8868BA1 , 24 avr. 2017)

Déball-arbres : Évitez les recherches ODB en double en double lors de la caisse

(ODB: Base de données d'objets)

Ensey Traverse_trees_Recursive () Pour ne pas faire des recherches ODB redondantes lorsque les deux répertoires se réfèrent au même OID.

dans des opérations telles que listre-arbores et caisse , il y aura probablement de nombreux répertoires pairs ayant le même OID lorsque les différences entre les commentations sont relativement petites. < BR> Dans ces cas, nous pouvons éviter de frapper plusieurs fois les ODB pour le même OID.

Ce correctif gère N = 2 et N = 3 cas et copie simplement les données plutôt que de répéter le rempliss_tree_descriptor (). xxx

sur le repo Windows (arbres 500K, 3,1 millions de fichiers, indice de 450 Mo), cela a réduit la durée totale de 0,75 seconde lors du cyclage entre 2 comme une seule différence de fichier. xxx

0 commentaires
1
votes

Après enquête, j'ai la preuve que la mauvaise performance devait faire avec les fichiers appartenant à un utilisateur d'un autre domaine. Plus précisément, je suis arrivé aux conclusions suivantes:

  • Je travaille dans un environnement d'entreprise avec plusieurs domaines et des milliers d'utilisateurs. Li>
  • En raison de changements organisationnels chaque utilisateur est, probablement au cours d'une phase de transition, maintenu dans deux domaines, son domaine principal ainsi qu'un second domaine. Lors d'un changement de propriété d'objet via l'interface graphique de Windows chaque utilisateur apparaît deux fois et il faut aller à la sélection de l'utilisateur étendu pour identifier celui affecté à un domaine spécifique. Li>
  • Cygwin acl strong> activé affiche le "autre domaine" utilisateur de fichier en tant que " + ". Le self de domaine principal est juste « ». Cygwin sans acl strong> affiche juste "" dans les deux cas. Cela peut être assez déroutant, car l'autorisation de fichiers et la propriété reconnu par Cygwin indiquerait l'autorisation d'écriture, alors que l'utilisateur ne dispose pas factuellement. Li>
  • les fichiers appartenant à l ' « autre domaine » auto sont inscriptibles par moi-même « ce domaine », de sorte que l'affectation de domaine est en grande partie transparente. Li>
  • Un grand arbre source de notre système de contrôle de version (qui a également été reflété dans une git) avait des milliers de fichiers appartenant à l ' « autre self domaine ». Cela semblait provoquer les opérations de fichiers lents. Changement de propriétaire à la fixe la question de la vitesse « self primaire de domaine », à la fois pour git et pour d'autres l'accès aux fichiers. Li> Ul>

    Je dois supposer que l'obtention d'autorisations de fichiers pour les utilisateurs dans d'autres domaines est lent, et pour une raison pas mises en cache (il était toujours le même utilisateur). P>

    Le reste de l'article ci-dessous est ce que je initialement posté. Je laisse reposer. P>

    Pour moi (travailler dans une grande entreprise avec de multiples domaines Windows distribués géographiquement) le coupable est que Cygwin utilise Windows acl par défaut. Considérez cette demande pour tous les utilisateurs connus dans le domaine: p> 

    none / cygdrive binary,posix=0,user,noacl 0 0

1 commentaires

Nice commentaires, plus précis que ma réponse. +1

Articles qui pourrait vous intéresser :

Comment gérer cet avertissement git? "Il est déconseillé de tirer sans préciser comment concilier des branches divergentes"
erreur: échec de la décompression à distance: eof avant la lecture complète de l'en-tête du pack
Valider / transmettre les modifications au référentiel Azure DevOps à la fin de la génération
Comment réparer `` Le projet que vous recherchiez est introuvable '' lors de l'utilisation de git clone