Pregunta

Estoy optimizando algunos códigos Perl que se ejecutan con frecuencia (una vez al día por archivo).

¿Los comentarios ralentizan los scripts de Perl? Mis experimentos se inclinan hacia el no:

use Benchmark;
timethese(20000000, {
    'comments' => '$b=1;
# comment  ... (100 times)
', 'nocomments' => '$b=1;'});

Da valores prácticamente idénticos (aparte del ruido).

Benchmark: timing 10000000 iterations of comments, nocomments...
  comments:  1 wallclock secs ( 0.53 usr +  0.00 sys =  0.53 CPU) @ 18832391.71/s (n=10000000)
nocomments:  0 wallclock secs ( 0.44 usr +  0.00 sys =  0.44 CPU) @ 22935779.82/s (n=10000000)

Benchmark: timing 20000000 iterations of comments, nocomments...
  comments:  0 wallclock secs ( 0.86 usr + -0.01 sys =  0.84 CPU) @ 23696682.46/s (n=20000000)
nocomments:  1 wallclock secs ( 0.90 usr +  0.00 sys =  0.90 CPU) @ 22099447.51/s (n=20000000)

Obtengo resultados similares si ejecuto los comentarios y las versiones sin comentarios como scripts de Perl separados.

Sin embargo, parece contrario a la intuición, si nada más el intérprete necesita leer los comentarios en la memoria cada vez.

¿Fue útil?

Solución

Perl es un lenguaje compilado justo a tiempo, por lo que los comentarios y el POD no tienen ningún efecto en el rendimiento en tiempo de ejecución.

Los comentarios y el POD tienen un efecto minúsculo en el tiempo de compilación, pero son tan fáciles y rápidos para que Perl los analice que es casi imposible medir el impacto en el rendimiento. Puedes ver esto por ti mismo usando la bandera -c para compilar.

En mi Macbook, un programa Perl con 2 declaraciones y 1000 líneas de comentarios de 70 caracteres tarda el mismo tiempo en compilarse como uno con 1000 líneas de comentarios vacíos como uno con solo 2 declaraciones impresas. Asegúrese de ejecutar cada punto de referencia dos veces para permitir que su sistema operativo guarde en caché el archivo; de lo contrario, lo que está comparando es el momento de leer el archivo desde el disco.

Si el tiempo de inicio es un problema para usted, no se debe a comentarios y POD.

Otros consejos

¿Rendimiento en tiempo de ejecución? No.

¿Análisis y rendimiento lexing? Sí, por supuesto.

Dado que Perl tiende a analizar y lex sobre la marcha, los comentarios afectarán "iniciar". rendimiento.

¿Lo afectarán notablemente? Poco probable.

Perl compila un script y luego lo ejecuta. Los comentarios ralentizan ligeramente la fase de compilación, pero no tienen ningún efecto en la fase de ejecución.

Perl no es un lenguaje de scripting en el mismo sentido que los scripts de shell. El intérprete no lee el archivo línea por línea. La ejecución de un programa Perl se realiza en dos etapas básicas: compilación y tiempo de ejecución [1]. Durante la etapa de compilación, el código fuente se analiza y se convierte en bytecode. Durante la etapa de tiempo de ejecución, el código de bytes se ejecuta en una máquina virtual.

Los comentarios ralentizarán la etapa de análisis, pero la diferencia es insignificante en comparación con el tiempo requerido para analizar el script en sí (que ya es muy pequeño para la mayoría de los programas). La única vez que realmente le preocupa el tiempo de análisis es en un entorno de servidor web en el que se puede llamar al programa muchas veces por segundo. mod_perl existe para resolver este problema.

Estás utilizando Benchmark . ¡Eso es bueno! Debería buscar formas de mejorar el algoritmo, no micro-optimización. Devel :: DProf podría ser útil para encontrar puntos calientes. Absolutamente no debe eliminar comentarios en un intento equivocado de hacer que su programa sea más rápido. Simplemente lo hará imposible de mantener.


[1] Esto se llama comúnmente "justo a tiempo" Compilacion. Perl en realidad tiene varias etapas más como INIT y END que no importan aquí.

El punto es: optimizar los cuellos de botella. La lectura en un archivo consiste en:

  • abriendo el archivo,
  • lectura en su contenido,
  • cerrando el archivo,
  • analizando el contenido.

De estos pasos, la lectura es la parte más rápida con diferencia (no estoy seguro de cerrar, es una llamada al sistema, pero no tiene que esperar a que termine). Incluso si es el 10% de todo (lo cual no es, creo), entonces reducirlo a la mitad solo mejora el rendimiento en un 5%, a costa de los comentarios faltantes (lo cual es algo muy malo). Para el analizador, tirar una línea que comienza con # no es una desaceleración tangible. Y después de eso, los comentarios se han ido, por lo que no puede haber desaceleración.

Ahora, imagine que realmente podría mejorar la "lectura en el guión" parte en un 5% eliminando todos los comentarios (que es una estimación realmente optimista, ver arriba). ¿Qué tan grande es la parte de "leer en el guión"? en el consumo de tiempo total del guión? Depende de cuánto lo hace, por supuesto, pero dado que los scripts perl generalmente leen al menos un archivo más, es un 50% como máximo, pero dado que los scripts perl generalmente hacen algo más, una estimación honesta reducirá esto a algo en el rango del 1% Entonces, la mejora de eficiencia esperada al eliminar todos los comentarios es en most (muy optimista) 2.5%, pero realmente más cerca de 0.05%. Y luego, aquellos en los que realmente da más del 1% ya son rápidos ya que no hacen casi nada, por lo que nuevamente está optimizando en el punto equivocado.

Concluyendo, optimice los cuellos de botella.

El módulo Benchmark es inútil en este caso. Solo mide los tiempos para ejecutar el código una y otra vez. Como su código en realidad no hace nada, la mayor parte está optimizado. Es por eso que lo ves funcionar 22 millones de veces por segundo.

Tengo casi todo el capítulo sobre esto en Mastering Perl . El error de medición en la técnica de referencia es aproximadamente del 7%. Sus números de referencia están bien dentro de eso, por lo que prácticamente no hay diferencia.

Del comentario de Paul Tomblins:

  
    

¿Perl no hace algún tipo de compilación sobre la marcha? ¿Quizás los comentarios se descartan temprano? -

  

Sí, Perl sí.

Es un lenguaje de programación entre compilado e interpretado. El código se compila sobre la marcha y luego se ejecuta. Los comentarios generalmente no hacen ninguna diferencia. Lo más probable sería que cuando analice inicialmente el archivo línea por línea y lo precompile, puede ver una diferencia de nano segundos.

Esperaría que el comentario solo se analizara una vez, no varias veces en el ciclo, por lo que dudo que sea una prueba válida.

Esperaría que los comentarios ralentizaran un poco la compilación, pero espero que sea demasiado pequeño para molestarse en eliminarlos.

¿Los comentarios de Perl ralentizan un script? Bueno, analizándolo, sí. ¿Ejecutarlo después de analizarlo? No. ¿Con qué frecuencia se analiza un script? Solo una vez, por lo que si tiene un comentario dentro de un bucle for, el comentario es descartado por los análisis una vez, incluso antes de que el script se ejecute, una vez que comenzó a ejecutarse, el comentario ya no está (y el script no se almacena internamente como script Perl), por lo tanto, no importa cuántas veces se repita el bucle for, el comentario no tendrá influencia. ¿Qué tan rápido puede omitir el analizador los comentarios? La forma en que se hacen los comentarios de Perl es muy rápida, por lo que dudo que lo note. Notará un mayor tiempo de inicio si tiene 5 líneas de código y entre cada línea 1 millón de líneas de comentarios ... pero ¿qué tan probable es eso y de qué utilidad sería un comentario tan grande?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top