Python 注释是否会减慢解释语言的速度?

Python 注释是否会减慢解释语言的速度?,python,comments,interpreter,interpreted-language,Python,Comments,Interpreter,Interpreted Language,我这样问是因为我使用Python,但它也可以应用于其他解释语言(Ruby、PHP、JavaScript) 每当我在代码中留下注释时,我是否会减慢解释器的速度?根据我对解释器的有限理解,它以字符串的形式读取程序表达式,然后将这些字符串转换为代码。似乎每次解析一条评论都是浪费时间 是这样吗?解释语言中的注释是否有某种约定,或者其影响可以忽略不计?注释通常在解析阶段或之前被剥离,并且解析非常快,因此有效地注释不会减慢初始化时间 这种作用在日常使用中是可以忽略的。它很容易测试,但是如果你考虑一个简单的循

我这样问是因为我使用Python,但它也可以应用于其他解释语言(Ruby、PHP、JavaScript)

每当我在代码中留下注释时,我是否会减慢解释器的速度?根据我对解释器的有限理解,它以字符串的形式读取程序表达式,然后将这些字符串转换为代码。似乎每次解析一条评论都是浪费时间


是这样吗?解释语言中的注释是否有某种约定,或者其影响可以忽略不计?

注释通常在解析阶段或之前被剥离,并且解析非常快,因此有效地注释不会减慢初始化时间

这种作用在日常使用中是可以忽略的。它很容易测试,但是如果你考虑一个简单的循环,比如:

For N = 1 To 100000: Next
你的电脑可以比你眨眼的速度更快地处理(数到100000)。忽略以某个字符开头的文本行将快10000倍以上


不要担心。

有注释会减慢启动时间,因为脚本将被解析为可执行形式。然而,在大多数情况下,注释不会降低运行时的速度


此外,在python中,您可以将.py文件编译成.pyc,其中不包含注释(我希望如此)-这意味着,如果脚本已经编译,您也不会获得启动成功。

对于python,源文件在执行之前编译(
.pyc
文件),在这个过程中,评论被剥离。因此,如果有无数条注释,它们可能会减慢编译时间,但不会影响执行时间。

我编写了一个简短的python程序,如下所示:

for i in range (1,1000000):
    a = i*10
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
这个想法是,做一个简单的计算负载的时间

通过计时,运行时间为0.35±0.01秒

然后我重写了它,插入了整个詹姆斯国王的《圣经》,如下所示:

for i in range (1,1000000):
    a = i*10
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
这次运行花费了0.4±0.05秒


所以答案是肯定的。循环中4MB的注释会产生可测量的差异。

这取决于解释器的实现方式。大多数合理的现代解释器在任何实际执行之前都会对源代码进行至少一点预处理,这将包括去掉注释,以便从那一点开始它们不会有任何区别

曾经,当内存受到严重限制时(例如,64K总可寻址内存和用于存储的盒式磁带),您不能将这种情况视为理所当然。回到苹果II、Commodore PET、TRS-80等的时代,程序员明确删除注释(甚至空格)以提高执行速度是相当常规的。这也是当时经常使用的许多源代码级黑客中的一种

当然,这些机器的CPU一次只能执行一条指令,时钟速度在1MHz左右,并且只有8位处理器寄存器,这也有所帮助。即使是一台你现在只能在垃圾箱里找到的机器也比以前快得多,所以它一点都不好笑


1.另一个例子是,在Applesoft中,根据行的编号方式,可以增加或减少一点速度。如果内存可用,则速度增益是goto语句的目标为16的倍数。

我对 解释器是用来读取程序的 中的表达式作为字符串和转换 将这些字符串转换为代码

大多数解释器读取文本(代码)并生成抽象语法树数据结构。
该结构不包含文本形式的代码,当然也不包含注释。仅此树就足以执行程序。但出于效率考虑,解释器更进一步,生成字节码。Python就是这样做的

我们可以说,代码和注释(以您编写的形式)根本不存在,
当程序运行时。因此,在运行时,注释不会减慢程序的速度

(*)不使用其他内部结构来表示文本以外的代码的解释器,

ie是一个语法树,必须完全按照你说的做。在运行时反复解释代码。

编写了一个类似Rich的脚本,并添加了一些注释(只有大约500kb的文本):


根据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)

正如其他答案已经指出的那样,像Python这样的现代解释语言首先解析源代码并将其编译成字节码,而解析器只是忽略注释。这显然意味着只有在实际解析源代码时,才会在启动时发生速度损失


由于解析器忽略注释,编译阶段基本上不受您输入的任何注释的影响。但是注释本身中的字节实际上是被读入的,然后在解析过程中被跳过。这意味着,如果您有大量的注释(例如数百兆字节),这将降低解释器的速度。但这同样会减慢任何编译器的速度。

我想知道注释的使用方式是否重要。例如,三重引号是docstring。如果您使用它们,则会验证内容。不久前,我在将一个库导入Python 3代码时遇到了一个问题。。。关于上的语法,我遇到了此错误。\N我查看了行号,它是三引号注释中的内容。我有点惊讶。对于Python来说,我从来没有想过块注释会被解释为语法错误

如果您键入:

'''
(i.e. \Device\NPF_..)
'''
Python 2没有抛出错误,但Python 3报告: SyntaxError:(unicode错误)'UnicodeScape'编解码器无法解码位置14-15中的字节:格式错误\N字符转义

因此,Python3显然在解释三重引号,确保其语法有效

但是,如果变成单行注释:#(即.\Device\NPF#)
没有错误结果

'''
(i.e. \Device\NPF_..)
'''
LABELS = [ "a1b1"
    "a1c1", 
    "a1d1", 
    "a1e1", 
    "a1f1",....]
import constants
np.array(constants.LABELS)
LABELS = [ "a1b1",  # 0 
            "a1c1", # 1
            "a1d1", # 2
            "a1e1", # 3
            "a1f1", # 4
             ...,
            "Q@h8", # 2271]