performance - español - mercurial source tree
TortoiseHg es lento (2)
Básicamente, lo que dice en la lata: TortoiseHg es lento.
Mi equipo se mudó de Subversion a Mercurial recientemente. (En parte, para aprovechar el horno para las revisiones de código). Una de las cosas que notamos es que interactuar con Mercurial a través de TortoiseHg es extremadamente lento. Algunas estadísticas:
- Abrir el banco de trabajo TortoiseHg: 8 minutos y 13 segundos
- Tiempo de respuesta al hacer clic en una revisión: 2.8 segundos
- Hora de "Actualizar repositorio actual": 6.4 segundos
- Hora de verificar si hay cambios entrantes: 12.8 segundos
Todo esto realmente se suma a una aplicación de sensación muy lenta. Como referencia, aquí están los tiempos de la herramienta de línea de comandos:
-
hg status: 4.573 segundos -
hg incoming: 12.150 segundos
Los tiempos de la línea de comandos parecen coincidir con los tiempos del banco de trabajo, pero el banco de trabajo hace que el retraso sea mucho más frustrante, porque es sincrónico con el uso del programa. Por ejemplo, una tarea típica es "obtener las últimas cosas que mi compañero de trabajo acaba de publicar". Se ve así (solo enumera el tiempo de espera en la computadora, redondeado):
- Open TortoiseHg: 10 minutos.
- Abra el depósito apropiado haciendo doble clic en el registro del repositorio: 5 segundos.
- Realice cambios locales que necesiten comprometerse:
- Haga clic en "Directorio de trabajo": 5 segundos.
- Seleccione archivos importantes y escriba un mensaje de confirmación.
- Presione Commit: 20 segundos.
- Obtener cambios de compañero de trabajo:
- Verifique los conjuntos de cambios entrantes: 10 segundos.
- Revísalos.
- Aceptar conjuntos de cambios entrantes: 40 segundos.
- Deje de lado los cambios no preparados:
- Diálogo Abrir estantería: 2 segundos.
- Guarde los archivos restantes: 6 minutos
- Actualizar: 5 segundos.
- Unir:
- Haga clic en la otra cabeza: 3 segundos.
- Fusionar con local:
- Espere a la verificación "limpia": 15 segundos.
- Espere a la fusión (suponiendo que no hay conflictos): 10 segundos.
- Compromiso: 30 segundos.
- Unshelve cambios:
- Diálogo Abrir estantería: 2 segundos.
- Unshelve: 6 minutos.
- Actualizar: 5 segundos.
Total: 24 minutos, 32 segundos.
Doce de esos minutos se gastan en estanterías y sin estanterías. Diez se gastan solo abriendo. Una consecuencia de esto es que las personas tienden a cometer cosas que no están seguras de ir a ninguna parte solo para evitar el costo de archivarlas. Pero incluso si supone que no tiene estanterías y no tiene un costo de apertura (tal vez solo lo deje abierto), todavía se necesitan 2 minutos y medio de clics meticulosos para obtener las últimas novedades.
Y eso ni siquiera cuenta las cosas más importantes como la clonación y otras cosas. Todo es tan lento
Yo tengo:
- Deshabilitado antivirus.
- Indización desactivada.
- Reiniciado
- Lo intenté en 3 versiones diferentes de Windows.
- Intenté hardware diferente, la mayoría de calidad razonable: Core 2 Duo @ 3.16 GHz, 8 Gb Ram.
- Lo intenté en sistemas operativos de 32 y 64 bit.
- Intenté desconectarlo de una red.
El repositorio es en realidad dos repositorios: un repositorio primario y un sub-repo que contiene todos nuestros binarios de terceros. La carpeta .hg del repositorio principal es 676 MB. La carpeta .hg del sub-repo es 641 MB. El contenido default en el repositorio principal es 7.05 GB. El contenido por default en el sub-repo es 642 MB. El tamaño promedio del archivo en el repositorio principal es de 563 KB. El tamaño máximo de archivo en el repositorio principal es de 170 MB. Hay 13,438 archivos en el repositorio principal. El tamaño promedio del archivo en el sub-repo es de 23 KB. El tamaño máximo de archivo en el sub-repo es 132 MB. Hay 57087 archivos en el sub-repo.
Tengo extensiones de gran empuje, caseguard, fetch, gestalt, kbfiles, horno, kilnauth, kilnpath, mq, purga y trasplante habilitados.
¿Alguna idea de dónde empezar a descubrir cómo acelerar las cosas? La lentitud nos está volviendo locos.
Ok, respondiendo mi propia pregunta porque encontré la respuesta mientras seguía el consejo de Tim.
El culpable es kbfiles de FogCreek. Deshabilitando los tiempos de estadísticas caídas de 12 segundos a .7 segundos. Del mismo modo, la GUI se abre más rápido de lo que puedo. Volver a habilitarlo hace que todo vuelva a disminuir drásticamente.
No parece que cada cosa lenta pueda ser culpada de los archivos kb, pero lo peor de eso puede ser. (Específicamente, shelve sigue siendo bastante lento, vinculado a la CPU. Sin embargo, podemos evitarlo).
Eso es un montón de archivos ... y algunos son terriblemente grandes. ¿Cómo funciona sin los archivos más grandes? Los archivos binarios no son exactamente lo mejor para rastrear con hg / git, en mi humilde opinión.
¿Qué hay de dividir el gran repositorio en otros más pequeños? ¿Realmente necesitan estar en 2 ENORMES repos?
Tal vez una defragmentación en los discos duros podría mejorar ligeramente algunos de esos momentos. También mire las extensiones que se han creado para ayudar a tratar específicamente con grandes archivos binarios. Mira aquí: