remote fetch is extremely slow
Personne n'a encore pris cette issue.
- Langage dominant
- Python
- Étoiles
- 1.7k
- Forks
- 408
- Merge moyen
- 2 j 57 min
- PR mergées (30 j)
- 7
Description
I have a tool that pulls down and installs a decent sized repository. Cloning the repo is fast and works well, however fetching subsequent updates is extremely slow. trying to figure out where the slowdown was coming from I ran my code through a profiler and obtained this result:
ncalls tottime percall cumtime percall filename:lineno(function)
1 0.001 0.001 616.895 616.895 \bkprocessor.py:1645(_startCacheUpdate)
1 0.000 0.000 405.243 405.243 AppData\Roaming\Python\Python37\site-packages\pygit2\remote.py:120(fetch)
1 404.655 404.655 405.243 405.243 {built-in method pygit2.libgit2.git_remote_fetch}
1 0.000 0.000 210.191 210.191 AppData\Roaming\Python\Python37\site-packages\pygit2_init.py:165(clone_repository)
1 204.704 204.704 210.191 210.191 {built-in method pygit2._libgit2.git_clone}
as you can see it cloned the repo in 210 seconds, pulling down nearly 1300 MB. during the clone additional commits came in and the subsequent fetch pulled down 42 MB quickly but then seemed to sit taking a total of 405 seconds, nearly twice as long as the clone operation.
Now I'm not sure exactly what in the fetch is taking so long, but whatever it is happens after retrieval of the data from the remote.
any advice on what I can do?
Guide de contribution
Ouvrir le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Piste de recherche
Commencez par reproduire la mise à jour lente avec la taille du dépôt et la sortie du profiler indiquées, en vous concentrant sur kprocessor.py:1645 (_startCacheUpdate) et le point d’entrée fetch de pygit2 remote.py. Comparez le temps passé dans git_remote_fetch avec celui passé dans clone_repository et identifiez quelle opération postérieure à la récupération est responsable du délai ; le travail est terminé lorsque le ralentissement est isolé et qu’un correctif ou un diagnostic exploitable est documenté.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Stack technique
- git, python
- Domaine
- performance
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- À l'abandon
- Clarté
- À clarifier
- Accessibilité débutants
- 25/100