Hay muchas razones por las que me gusta usar Vim como mi editor principal. La velocidad y la personalización son dos de ellas, pero si tuviera que decidir entre las dos, preferiría tener velocidad. Esta es una historia sobre cómo puede usar el análisis de rendimiento de Vim para capturar complementos lentos.

El otro día me encontré abriendo un archivo diff que tardó mucho en cargar. El archivo tenía 58187 (este número será importante más adelante) líneas en él, pero nunca pensé que Vim se atragantaría con algo de menos de 2M de tamaño.

Buscando en Google descubrí que puedes analizar el rendimiento de Vim muy fácilmente, para ver dónde se pasa el tiempo mientras se carga un archivo. Todo lo que tenía que hacer era

  1. Abra Vim e inicie el análisis de rendimiento

     :profile start /tmp/profile.log
     :profile func *
     :profile file *
    

    Esto le dice a Vim que guarde los resultados del análisis en /tmp/profile.log y que ejecute el análisis para cada archivo y función.

  2. Luego, realice la acción que llevaba mucho tiempo en Vim, en mi caso, abrir el archivo diff.

     :edit /tmp/file.diff
     :profile pause
     :q!
    

    El archivo profile.log solo se genera hasta que cierre Vim.

  3. Ahora puede abrir profile.log y analizar los datos.

    Hay mucha información en este archivo, pero puede comenzar centrándose en el tiempo total Total time. ¡En mi caso hubo un delincuente claro con un tiempo total de más de 14 segundos!

     FUNCTION <SNR>24_PreviewColorInLine() 
     Called 58187 times 
     Total time: 14.430544 
      Self time: 2.961442
    

    Recuerde la cantidad de líneas en el archivo. Para mí fue interesante ver que la función se llama la misma cantidad de veces.

  4. Averiguar dónde se define esta función es muy fácil

    Gracias a la etiqueta <SNR> y al número justo después. Simplemente necesita ejecutar :scrptnames y desplazarse hasta encontrar el número de índice que está buscando, en mi caso 24.

     24: ~/.vim/bundle/colorizer/autoload/colorizer.vim
    

Personalmente, no creo que el beneficio que puede aportar un complemento sea aceptable a costa de hacer que la funcionalidad trivial, como abrir un archivo, tarde un cuarto de minuto, así que lo eliminé y abrí un reporte explicando el problema en GitHub. Pero con el conocimiento de qué función está causando el problema, también puede llegar a la tarea de solucionarlo.

Actualización: el reporte nunca se abordó, por lo que tal vez el proyecto no se mantenga.