usa sirve quien que programacion porque para industria guido creator aplicaciones python comments interpreter interpreted-language

sirve - python guido



¿Los comentarios frenan un lenguaje interpretado? (10)

Lo pregunto porque uso Python, pero podría aplicarse también a otros lenguajes interpretados (Ruby, PHP, JavaScript).

¿Estoy reduciendo la velocidad del intérprete cada vez que dejo un comentario en mi código? De acuerdo con mi comprensión limitada de un intérprete, lee expresiones de programa como cadenas y luego convierte esas cadenas en código. Parece que cada vez que se analiza un comentario, se pierde tiempo.

¿Es este el caso? ¿Existe alguna convención para comentarios en idiomas interpretados o el efecto es insignificante?


Mi comprensión limitada de un intérprete es que lee expresiones de programa como cadenas y convierte esas cadenas en código.

La mayoría de los intérpretes leen el texto (código) y producen una estructura de datos del árbol de sintaxis abstracta.
Esa estructura no contiene ningún código, en forma de texto, y por supuesto tampoco hay comentarios. Solo ese árbol es suficiente para ejecutar programas. Pero los intérpretes, por razones de eficiencia, van un paso más allá y producen un código de bytes. Y Python hace exactamente eso.

Podríamos decir que el código y los comentarios, en la forma en que los escribió, simplemente no están presentes ,
cuando el programa se está ejecutando. Así que no, los comentarios no ralentizan los programas en tiempo de ejecución.

(*) Intérpretes que no usan alguna otra estructura interna para representar el código que no sea texto,
Es decir, un árbol de sintaxis, debe hacer exactamente lo que usted mencionó. Interpreta una y otra vez el código en tiempo de ejecución.


Bueno, escribí un programa corto de python como este:

for i in range (1,1000000): a = i*10

La idea es, hacer un simple cálculo de las veces.

Al cronometrar eso, tardó 0.35 ± 0.01 segundos en ejecutarse.

Luego lo reescribí con toda la Biblia King James insertada así:

for i in range (1,1000000): """ The Old Testament of the King James Version of the Bible The First Book of Moses: Called Genesis 1:1 In the beginning God created the heaven and the earth. 1:2 And the earth was without form, and void; and darkness was upon the face of the deep. And the Spirit of God moved upon the face of the waters. 1:3 And God said, Let there be light: and there was light. ... ... ... ... Even so, come, Lord Jesus. 22:21 The grace of our Lord Jesus Christ be with you all. Amen. """ a = i*10

Esta vez tardó 0.4 ± 0.05 segundos en ejecutarse.

Así que la respuesta es . 4MB de comentarios en un bucle hacen una diferencia medible.


Como ya se ha dicho en otras respuestas, un lenguaje interpretado moderno como Python primero analiza y compila la fuente en el código de bytes, y el analizador simplemente ignora los comentarios. Esto claramente significa que cualquier pérdida de velocidad solo se producirá en el inicio cuando la fuente se analiza realmente.

Debido a que el analizador ignora los comentarios, la fase de compilación básicamente no se ve afectada por los comentarios que usted ingrese. Pero los bytes en los comentarios en sí mismos se leen en realidad, y luego se omiten durante el análisis. Esto significa que, si tiene una gran cantidad de comentarios (por ejemplo, muchos cientos de megabytes), esto ralentizaría al intérprete. Pero, de nuevo, esto también ralentizaría a cualquier compilador.


Depende de cómo se implemente el intérprete. La mayoría de los intérpretes razonablemente modernos realizan al menos un poco de preprocesamiento en el código fuente antes de cualquier ejecución real, y eso incluirá eliminar los comentarios para que no hagan ninguna diferencia a partir de ese punto.

En un momento dado, cuando la memoria estaba severamente restringida (por ejemplo, la memoria direccionable total de 64K y las cintas de cassette para el almacenamiento) no podía darse por sentado. En el día de Apple II, Commodore PET, TRS-80, etc., era bastante habitual que los programadores eliminaran explícitamente los comentarios (e incluso el espacio en blanco) para mejorar la velocidad de ejecución. Este fue también uno de los muchos hacks a nivel de código fuente empleados habitualmente en el momento 1 .

Por supuesto, también ayudó que esas máquinas tuvieran CPU que solo podían ejecutar una instrucción a la vez, tenían velocidades de reloj de aproximadamente 1 MHz y solo tenían registros de procesador de 8 bits. Incluso una máquina que encontrarías ahora solo en un contenedor de basura es mucho más rápida que esas que ni siquiera es graciosa ...

1. Por otro ejemplo, en Applesoft puedes ganar o perder un poco de velocidad dependiendo de cómo numeraste las líneas. Si la memoria sirve, la ganancia de velocidad fue cuando el objetivo de una instrucción goto era un múltiplo de 16.


El efecto es despreciable para el uso diario. Es fácil de probar, pero si considera un bucle simple como:

For N = 1 To 100000: Next

Su computadora puede procesar eso (contar hasta 100,000) más rápido de lo que puede parpadear. Ignorar una línea de texto que comienza con un cierto carácter será más de 10,000 veces más rápido.

No te preocupes por eso.


Hice un guión como el de Rich con algunos comentarios (solo unos 500kb de texto):

# -*- coding: iso-8859-15 -*- import timeit no_comments = """ a = 30 b = 40 for i in range(10): c = a**i * b**i """ yes_comment = """ a = 30 b = 40 # full HTML from http://en.wikipedia.org/ # wiki/Line_of_succession_to_the_British_throne for i in range(10): c = a**i * b**i """ loopcomment = """ a = 30 b = 40 for i in range(10): # full HTML from http://en.wikipedia.org/ # wiki/Line_of_succession_to_the_British_throne c = a**i * b**i """ t_n = timeit.Timer(stmt=no_comments) t_y = timeit.Timer(stmt=yes_comment) t_l = timeit.Timer(stmt=loopcomment) print "Uncommented block takes %.2f usec/pass" % ( 1e6 * t_n.timeit(number=100000)/1e5) print "Commented block takes %.2f usec/pass" % ( 1e6 * t_y.timeit(number=100000)/1e5) print "Commented block (in loop) takes %.2f usec/pass" % ( 1e6 * t_l.timeit(number=100000)/1e5)


C:/Scripts>timecomment.py Uncommented block takes 15.44 usec/pass Commented block takes 15.38 usec/pass Commented block (in loop) takes 15.57 usec/pass C:/Scripts>timecomment.py Uncommented block takes 15.10 usec/pass Commented block takes 14.99 usec/pass Commented block (in loop) takes 14.95 usec/pass C:/Scripts>timecomment.py Uncommented block takes 15.52 usec/pass Commented block takes 15.42 usec/pass Commented block (in loop) takes 15.45 usec/pass

Editar según el comentario de David:

-*- coding: iso-8859-15 -*- import timeit init = "a = 30/nb = 40/n" for_ = "for i in range(10):" loop = "%sc = a**%s * b**%s" historylesson = """ # <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" # blah blah... # --></body></html> """ tabhistorylesson = """ # <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" # blah blah... # --></body></html> """ s_looped = init + "/n" + for_ + "/n" + tabhistorylesson + loop % ('' '',''i'',''i'') s_unroll = init + "/n" for i in range(10): s_unroll += historylesson + "/n" + loop % ('''',i,i) + "/n" t_looped = timeit.Timer(stmt=s_looped) t_unroll = timeit.Timer(stmt=s_unroll) print "Looped length: %i, unrolled: %i." % (len(s_looped), len(s_unroll)) print "For block takes %.2f usec/pass" % ( 1e6 * t_looped.timeit(number=100000)/1e5) print "Unrolled it takes %.2f usec/pass" % ( 1e6 * t_unroll.timeit(number=100000)/1e5)


C:/Scripts>timecomment_unroll.py Looped length: 623604, unrolled: 5881926. For block takes 15.12 usec/pass Unrolled it takes 14.21 usec/pass C:/Scripts>timecomment_unroll.py Looped length: 623604, unrolled: 5881926. For block takes 15.43 usec/pass Unrolled it takes 14.63 usec/pass C:/Scripts>timecomment_unroll.py Looped length: 623604, unrolled: 5881926. For block takes 15.10 usec/pass Unrolled it takes 14.22 usec/pass


Los comentarios generalmente se eliminan en o antes de la etapa de análisis, y el análisis es muy rápido, por lo que los comentarios no ralentizarán el tiempo de inicialización.


Me pregunto si importa cómo se usan los comentarios. Por ejemplo, las comillas triples son una cadena de documentación. Si los usas, el contenido es validado. Me encontré con un problema hace tiempo cuando importaba una biblioteca en mi código de Python 3 ... Recibí este error relacionado con la sintaxis en / N. Miré el número de línea y estaba contenido dentro de un comentario de cita triple. Me sorprendió un poco Como novedad en Python, nunca pensé que un comentario de bloque se interpretaría para los errores de sintaxis.

Simplemente si escribe:

'''''' (i.e. /Device/NPF_..) ''''''

Python 2 no genera un error, pero Python 3 informa: SyntaxError: (error de Unicode) El códec ''Unicodeescape'' no puede decodificar bytes en la posición 14-15: escape de caracteres / N mal formado

Entonces, Python 3 está interpretando evidentemente la cita triple, asegurándose de que sea una sintaxis válida.

Sin embargo, si se convierte en un solo comentario de línea: # (es decir, / Dispositivo / NPF_ ..)
No hay resultados de error.

Me pregunto si los comentarios de la cita triple se reemplazaron con líneas simples, si se vería un cambio en el rendimiento.


Tener comentarios ralentizará el tiempo de inicio, ya que los scripts se analizarán en una forma ejecutable. Sin embargo, en la mayoría de los casos, los comentarios no ralentizan el tiempo de ejecución.

Además, en Python, puede compilar los archivos .py en .pyc, que no contendrán los comentarios (espero), esto significa que tampoco obtendrá un hit de inicio si el script ya está compilado.


Para el caso de Python, los archivos de origen se compilan antes de ejecutarse (los archivos .pyc ), y los comentarios se eliminan en el proceso. Por lo tanto, los comentarios podrían ralentizar el tiempo de compilación si tiene millones de ellos, pero no afectarán el tiempo de ejecución.