libgit2 / libgit2/pygit2

remote fetch is extremely slow

Abierto
#1,146 0 comentarios 1 reacción 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
Python
Estrellas
1.7k
Forks
408
Merge medio
2 d 57 min
PR fusionados (30 d)
7

Descripción

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?

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza reproduciendo la actualización lenta con el tamaño del repositorio y la salida del profiler indicados, centrándote en kprocessor.py:1645 (_startCacheUpdate) y en el punto de entrada de fetch de pygit2 remote.py. Compara el tiempo empleado en git_remote_fetch con el empleado en clone_repository e identifica qué operación posterior a la recuperación es la responsable del retraso; se considera terminado cuando la ralentización está aislada y se ha documentado una solución o diagnóstico accionable.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
git, python
Área
performance
Tipo de issue
Error
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.