2008-11-06 17 views
7

Estoy optimizando algunos códigos Perl que se ejecutan con frecuencia (una vez al día por archivo).¿Los comentarios afectan el rendimiento de Perl?

¿Los comentarios retrasan los scripts de Perl? Mis experimentos se inclinan por no:

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

Proporciona 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) 

puedo obtener resultados similares si se me acaban los comentarios y versiones sin comentarios como scripts de Perl separadas.

Parece contra-intuitivo, sin embargo, si nada más el intérprete necesita leer los comentarios en la memoria cada vez.

+0

¿No hace Perl hacer algún tipo de compilación sobre la marcha? Tal vez los comentarios se descartan temprano? –

+0

Quizás no esté agregando suficientes comentarios para marcar la diferencia. –

+0

Apuesto a que las nuevas líneas también disminuyen lentamente. Deberías hacer como los verdaderos maestros de Perl, y poner todo tu código en una sola línea. – davr

Respuesta

13

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

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

En mi Macbook, un programa de Perl con 2 declaraciones y 1000 líneas de 70 caracteres de comentarios toma el mismo tiempo para compilar uno con 1000 líneas de comentarios vacíos que con solo 2 declaraciones de impresión. 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á evaluando es el momento de leer el archivo desde el disco.

Si el tiempo de inicio es un problema para usted, no es por los comentarios y el POD.

+0

Así que la respuesta que voy es apenas, gracias a todos. – Dave

8

Perl compila una secuencia de comandos y luego la ejecuta. Los comentarios reducen ligeramente la fase de compilación, pero tienen un efecto nulo en la fase de ejecución.

18

¿Desempeño en tiempo de ejecución? No.

Analizando y leyendo rendimiento? Sí, por supuesto.

Dado que Perl tiende a analizar y leer sobre la marcha, los comentarios afectarán el rendimiento de "inicio".

¿Lo afectarán notoriamente? Improbable.

0

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

Supongo que los comentarios ralentizarán ligeramente la compilación, pero espero que sea muy poco importante molestarse en eliminarlos.

1

De Paul comentario Tomblins:

no Perl hacer algún tipo de compilación sobre la marcha? Tal vez los comentarios se descartan temprano? -

Sí Perl does.

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áximo que probablemente suceda es que cuando inicialmente analiza el archivo línea por línea y lo compila previamente, es posible que vea una diferencia de nano segundos.

0

¿Los comentarios de Per Perl ralentizan la secuencia de comandos? Bueno, analizándolo, sí. ¿Ejecutarlo después de analizarlo? No. ¿Con qué frecuencia se analiza un script? Solo una vez, así que si tiene un comentario dentro de un ciclo for, el comentario es descartado por el analizador una vez, antes de que el script se ejecute, una vez que comenzó a ejecutarse, el comentario ya se ha ido (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á ninguna influencia. ¿Qué tan rápido puede omitir el analizador los comentarios? La forma en que los comentarios de Perl se hacen, muy rápido, por lo tanto, dudo que lo notes. Notará un mayor tiempo de inicio si tiene 5 líneas de código y entre cada línea 1 Mio de líneas de comentarios ... pero ¿qué tan probable es eso y de qué sirve un comentario así de grande?

7

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 bytecode 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 te 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 usando Benchmark. ¡Eso es bueno! Debería buscar formas de mejorar el algoritmo, no micro optimizando. Devel :: DProf puede ser útil para encontrar los puntos calientes. Usted absolutamente no debería pelar comentarios en un intento equivocado de hacer que su programa sea más rápido. Lo dejarás sin mantenimiento.


[1] Esto se conoce comúnmente como compilación "just in time". Perl en realidad tiene varias etapas más como INIT y END que no importan aquí.

+0

Devel :: DProf es el viejo quebrado con solo perfiles de nivel de subrutina. Devel :: NYTProf es el nuevo hotness con una granularidad más fina. –

3

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

  • abrir el archivo,
  • lectura en su contenido,
  • cerrar el archivo,
  • analizar el contenido.

De estos pasos, leer es la parte más rápida de lejos (no estoy seguro acerca de cerrar, es un syscall, pero no tiene que esperar que termine). Incluso si es el 10% de todo (lo que no es, creo), reducirlo a la mitad solo da un 5% de rendimiento mejorado, a costa de perder los comentarios (lo cual es algo muy malo). Para el analizador sintáctico, tirar una línea que comienza con # no es una ralentización tangible. Y después de eso, los comentarios se han ido, por lo que no puede haber desaceleración.

Imagine que puede mejorar la parte de "lectura en el script" en un 5% mediante la eliminación de todos los comentarios (lo que es una estimación muy optimista, consulte más arriba). ¿Qué tan grande es la cuota de "lectura en el guión" en el consumo general de tiempo del guión? Depende de cuánto, por supuesto, pero dado que los scripts Perl generalmente leen al menos un archivo más, es 50% como máximo, pero dado que los scripts Perl usualmente hacen algo más, una estimación honesta lo reducirá a algo dentro del rango del 1%. Entonces, la mejora de eficiencia esperada al eliminar todos los comentarios es enmás (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 vuelves a optimizar en el punto equivocado.

Concluir, optimizar los cuellos de botella.

+0

Si tuviera que agregar una entrada, señalaría que los comentarios al final de la línea son de lejos los más fáciles de descartar. Perldoc es probablemente el siguiente más fácil: línea completa, no se puede anidar (cuando dices = cortar, ya está hecho), bloque de líneas definido ... – Axeman

+0

ACTualmente, leer un archivo comienza con la búsqueda del archivo. Si Perl tiene que buscar a través de un largo @INC, eso podría ser significativo. Ver, por ejemplo, http://www.perl.com/lpt/a/2005/12/21/a_timely_start.html –

+0

Sí, pero aquí asumí una invocación directa que incluye una ruta. Si algún trabajo cron no especifica la ubicación del guión, entonces es un cuello de botella que realmente vale la pena optimizar. – Svante

2

El módulo de referencia es inútil en este caso. Solo mide los tiempos para ejecutar el código una y otra vez. Como el código no hace nada, la mayor parte se optimiza. Es por eso que lo ves correr 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 Benchmark es de aproximadamente 7%. Sus números de referencia están dentro de eso, por lo que prácticamente no hay diferencia.

Cuestiones relacionadas