Rendimiento de aplicaciones

[ARCHIVADO] Última actualización realizada por Joe Schaefer en vie., 26 abr. 2024    origen
 

Muchos desarrolladores caen en la trampa de pensar que la optimización del rendimiento consiste en hacer que cada línea de código sea lo más eficiente posible.

En realidad es todo lo contrario. Comienza con las restricciones arquitectónicas de la aplicación y las utiliza para aumentar detalle hasta la parte “más lenta” observada del programa. La implantación de esa parte guía todas las demás opciones de rendimiento que necesita realizar. Cualquier cosa que no sea tan lenta como esa parte, no necesita ser optimizada aún más. En su lugar, centrarse en la expresión humana y la simplicidad y claridad de la implementación, a los lectores no expertos sobre la Modelo:SSL

Puedes iterar en este libro de estrategias, pero nunca he tenido que ir más allá de 3 iteraciones en mi carrera profesional.

Así que adelante y utiliza un lenguaje de programación elegante como Python3 o Archivo Javascript/Tipo de letray deje que los expertos en la materia (SME) que hay en el mundo de código abierto le den una poderosa C/C++

Incluso una secuencia de comandos bash libre de dependencias es una solución viable para muchas tareas básicas. He aquí uno que escribí para la firma de Realidad Aumentada Salto mágico años, para sustituir a un torpe OpenGrok servicio con algo que aprovecha la paralelización multiprocesador con xargs -P, y apoya PCRE buscar con simple Emacs/Vim

https://github.com/joesuf4/home/blob/wsl/bin/pffxg.sh

Ese script es un orden de magnitud más rápido que los sospechosos habituales en GitHub, que se escribieron en lenguajes de programación compilados y estáticos. Pero al identificar el cuello de botella exacto en bash (en bucle con alto volumen bifurcación + ejecución llamadas en el medio), y utilizando xargos en su lugar, se obtiene un script que se parece mucho a este, con el algoritmo principal implementado en 10 líneas de shell

También está utilizando la comunidad de código abierto de PYME de una manera inteligente, en lugar de la forma en que lo hicieron las otras implementaciones de “grep recursivo filtrado” en GitHub. En lugar de adoptar y mantener internamente mi propia implementación (threaded) de buscar, xargos, y verde, acabo de reutilizar los ejecutables preinstalados que otras PYME han estado perfeccionando durante décadas tal cual. No necesito dominar sus implementaciones, solo reutilizarlas CLI

Para ver la tachuela opuesta, donde todo se hace internamente, completamente microoptimizado, y aún así no puede vencer a este script con las opciones de búsqueda predeterminadas, y no hay un sistema de almacenamiento en caché disponible, aquí hay un buen ejemplo https://github.com/BurntSushi/ripgrep

Solo para extraer el primer #performance #benchmark de esa página y escalarlo desde un tamaño de árbol de muestra de juguete (fuentes de núcleo linux) hasta un árbol heterogéneo que sea 23GB: (mejores carreras después de 3 iteraciones; LANG=en_US.UTF-8

    % du -sh .
    23G .
    % time rg -uuniw '[A-Z]+_SUSPEND' | wc -l
    6259
    rg -uuniw '[A-Z]+_SUSPEND' 9.46s user 16.08s system 261% cpu 9.759 total
    wc -l 0.00s user 0.07s system 0% cpu 9.759 total
    % time pffxg.sh -- -wnE '[A-Z]+_SUSPEND' | wc -l
    5855
    pffxg.sh -- -wnE '[A-Z]+_SUSPEND' 16.66s user 2.68s system 429% cpu 4.501 total
    wc -l 0.00s user 0.00s system 0% cpu 4.501 total

Es bastante tonto microoptimizar algo que está profundamente ligado al estado de la caché del sistema de archivos del núcleo para su búsqueda. La variación de los tiempos de rendimiento está dominada por la velocidad de acceso al corpus de contenido de los archivos, y es un orden de magnitud más relevante que cualquier otro factor para los resultados finales. Estar en NVMe ayuda, pero nada en este espacio late RAM

Es por eso que tener una caché comprimida en memoria para un gran corpus de archivos, estabilizará los tiempos de rendimiento. Es sorprendente que nadie más pensara que esto era lo suficientemente importante como para apoyar.

Desactive la segunda #performance #benchmark de esa página y amplíela verticalmente como antes (igual que 23GB

    % time rg -tc -uuuiwn '[A-Z]+_SUSPEND' | wc -l
    5629
    rg -tc -uuuiwn '[A-Z]+_SUSPEND' 3.51s user 1.71s system 1141% cpu 0.457 total
    wc -l 0.00s user 0.05s system 11% cpu 0.457 total
    % time LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE '[A-Z]+_SUSPEND' | wc -l
    5628
    LANG=C pffxg.sh --cache /tmp/pffxg-$USER --workers 32 --cc -- -wE  3.14s user 0.88s system 1055% cpu 0.381 total
    wc -l 0.00s user 0.00s system 0% cpu 0.381 total

A sintonizado pffxg.sh todavía es más rápido, a pesar de todo el trabajo puesto en microoptimización ripgrep para este C

La forma en que usé este guión con AOSP era programar un repositorio sincronización y una posterior pffxg.sh lzop-compressed-cache seed-to-tmpfs correr todas las mañanas antes del trabajo (via crontab), con PFFXG_CACHE=... establecido en mi ~/.pffxg.conf archivo. Así pues, cualquier pffxg.sh las llamadas que he ejecutado durante el día laborable utilizarían la caché comprimida en tmpfs

.25M de LOC entre ripgrep y ugrep. 632 LOC para pffxg.sh

Porque es un programa de shell tan pequeño, pffxg.sh puede darle poderosos ganchos en sus interiores con casi cero esfuerzo. Incluso el verde El comando en sí es personalizable: cualquier comando que necesite ejecutar en un corpus selecto de archivos, que puede aceptar una lista de nombres de archivo anexados al final de sus argumentos, es un juego justo. Aquí hay un “recuento total de líneas en MiLOC

    % time find * -type f | xargs wc -l | awk '{ $2 == "total" {a+=$1} END {print a/1024**2}'
    28.451
    find * -type f 0.00s user 0.06s system 2% cpu 2.733 total
    xargs wc -l 0.53s user 1.02s system 54% cpu 2.853 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.23s user 0.59s system 28% cpu 2.853 total

    % time pffxg.sh --workers 8 --cmd wc --all -- -l | awk '{$2 == "total" {a+=$1} END {print a/1024**2}'
    28.4506
    pffxg.sh --workers 8 --cmd wc --all -- -l 0.92s user 0.66s system 826% cpu 0.192 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 11% cpu 0.192 total

ripgrep

    % time rg -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    28.4284
    rg -c \$ 2.12s user 2.19s system 276% cpu 1.564 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.58s user 0.45s system 66% cpu 1.564 total

Aquí se limita a C

    % time pffxg.sh --workers 8 --cc --cmd wc -- -l | awk '$2 == "total" {a+=$1} END {print a/1024**2}'
    25.3935
    pffxg.sh --workers 8 --cc --cmd wc -- -l 0.76s user 0.54s system 734% cpu 0.177 total
    awk '$2 == "total" {a+=$1} END {print a/1024**2}' 0.02s user 0.00s system 9% cpu 0.177 total

y el ripgrep

    % time rg -tc -c \$ | awk -F : '{a+=$2} END {print a/1024**2}'
    25.3844
    rg -tc -c \$ 3.49s user 1.54s system 441% cpu 1.140 total
    awk -F : '{a+=$2} END {print a/1024**2}' 0.38s user 0.38s system 66% cpu 1.140 total

El verdadero rendimiento de aplicación proviene del equilibrio, la flexibilidad y las técnicas de programación funcional; no proviene de la fijación de tácticas de microoptimización imperativas en lenguajes de programación estáticos y compilados que son un oso para trabajar desde las perspectivas de equilibrio y flexibilidad. Estos lenguajes imperativos sobrevalorados son grandes objetivos para dominios de problemas muy específicos, pero son terribles para el rendimiento de las aplicaciones de todo el sistema.

pffxg.sh no es un producto, y esto no es un argumento de venta para él. Es un ejemplo para ilustrar mi punto de una manera muy dramática. Si está familiarizado con la larga historia de las soluciones “grep” recursivas filtradas en GitHub, todas ellas se basan en la idea de que el problema con el original de Andy Lester Perl implementación confirmación, fue que fue escrito en Perl. El único problema real desde el punto de vista del rendimiento fue que Perl fue escrito por Andy, que no parecía tener ningún don para los conceptos de rendimiento de los sistemas (como cultivar el buscar trabajo de paralelización a un diseño específico C binario), sino que apuntaba a la portabilidad perezosa al tratar de capturar todo el código como un Pure de un solo hilo. Perl

¡Que florezcan mil flores, por tontas que parezcan!

Enlace permanente 

 

   

Comentarios  


Anexos  

Enlaces  


Índice

 

  • Git y no repudio — Hay una clara distinción entre la historia del “compromiso” y la historia de la “carga” … vie., 03 may. 2024

 

  • Listas de correo — Estas direcciones temporales son un anatema para ezmlm-idxsistemas de suscripción y moderación … vie., 03 may. 2024

 



 

  • La alegría de DTrace — Medir dos veces, cortar una vez, antes de embarcarse en un esfuerzo de optimización de código … mié., 17 abr. 2024

 


Marzo 2020 COVID-19

  • Crecimiento exponencial y COVID-19 — Tómese su tiempo con la sección de matemáticas — Es importante ser un consumidor educado de estadísticas relevantes para la pandemia actual … lun., 30 ene. 2023

 


 


Panal hiperbólico


 

  • Diversión con htop — Funciones avanzadas de htop en plataformas populares de Unix … jue., 19 ene. 2023

Arquitectura de la Información

  • Arquitectura de la Información — Toda la gama de tecnologías relevantes para el diseño, la presentación, las relaciones y las restricciones arquitectónicas que cubren cada URL que sirve … lun., 11 mar. 2024

alquitranados y emplumados


Dependencias de idioma inglés


 

  • Movimiento DevOps — La gran idea detrás del “movimiento” no es simplemente dar a los desarrolladores más cuerda … vie., 26 abr. 2024

Año del Dragón