这是我一直想知道的事情，所以这里有。
在编写代码时，我/我被教导要分隔线，评论它们等......以提高可读性（正如我猜我们大多数人所做的那样）。我显然不认为这是一个任何问题，但它让我思考，如果所有这些空白和注释部分被编译器/解释器或其他任何东西忽略，这会对它的性能产生多大影响？ / p>
不可否认，我不太了解编译器的运行方式 - 只有基本概念。但是，我有一个公平的想法，一个人能够“忽略空白”，它首先需要识别它（至少），这需要工作，因此需要时间。
那么我想，极端水平的空白或评论呢？比方说，数百万或数十亿的部分？
我想我问的问题是：在什么时候（即极端级别）会忽略代码部分会影响编译器/解释器产生及时结果的能力，从而影响用户的体验？
感谢。
答案 0 :(得分：5)
它不会像单词暗示的那样影响编译数据。但请不要评论腹泻，这会影响其他程序员的表现。
答案 1 :(得分：3)
试试这个：
Do comments affect Perl performance?
编辑评论。
使用Scheme中的hello world以及不同数量的注释行的简单示例：
netbsd1# ls -l file*
-rw-r--r-- 1 root wheel 1061 Mar 11 00:01 file.out
-rw-r--r-- 1 root wheel 102041 Mar 11 00:01 file1.out
-rw-r--r-- 1 root wheel 10200041 Mar 11 00:01 file2.out
-rw-r--r-- 1 root wheel 1020000041 Mar 11 00:03 file3.out
netbsd1# for i in file*
> do
> echo $i
> time ./scm $i
> done
file.out
hello world
0.06s real 0.01s user 0.01s system
file1.out
hello world
0.03s real 0.01s user 0.02s system
file2.out
hello world
0.64s real 0.28s user 0.30s system
file3.out
hello world
61.36s real 11.78s user 41.10s system
netbsd1#
显然，1GB文件产生了重大影响，考虑到我这个盒子里只有512M的RAM，这并不奇怪。
此外，这是解释/编译速度。如果您实际编译了这些文件，则运行时将完全相同。您可以得出定义影响的结论。
答案 2 :(得分：1)
编译（和链接）是第1阶段。
执行是第2阶段。
由于阶段1至少为O（输入长度），因此您可以预期阶段1需要与输入长度成比例（至少）。 如果文件长度低于10 ^ 4行，它可能不会打扰你太多。 如果文件长度为10 ^ 12行，则可能需要数年时间，如果某些内容没有先破坏。
但这不会影响第2阶段。第2阶段的影响是程序的工作量以及需要需要做多少工作。
答案 3 :(得分：1)
如果你正在谈论一个已编译的二进制文件，那么对性能的影响恰好是0 - 它们只是执行的一系列指令，在这个意义上，空格并不是真正存在的概念。如果你在谈论解释语言，那么我想理论上数百万行的空白可能对性能产生非常小的影响，但还不足以引起注意。
简而言之，虽然从学术角度来看这是一个有趣的问题但是你不应该担心，无论你是使用编译语言还是解释语言。始终支持可读性和评论。如果你引用性能的原因是不使用空格或注释，那么代码的未来维护者将会出来帮助你！
答案 4 :(得分：1)
取决于。
在编译语言中，编译可能需要更长时间，但您可能不关心，因为这样做了一次。
在解释型语言中，如果解释器将文本保存在内存中，则会浪费加载时间，执行时间和更多内存使用。
在将JavaScript传递到浏览器之类的内容中，您不仅需要担心解析时间，还需要将所有这些注释传输到客户端的浏览器。因此，很多人会通过一个minifier来运行他们的脚本，这个minifier会提取注释并做其他技巧来减少代码大小。
对于严重过度评论的代码，受到代码生成器，过度热心的修订控制系统和“宗教评论者”所发出的评论的困扰，我实际上会更担心那些不得不涉及所有人的读者/评论者。大多数无用且可能不同步的文本来获取代码。
答案 5 :(得分：0)
源文件中的空格对用户体验没有任何影响。一旦编译了二进制文件，那就是那个。如果编译器使用 delta-t 更长时间来解析源代码并不重要，因为有数百万条注释。
答案 6 :(得分：0)
白色空间会影响白色空间编译成机器指令时的性能。幸运的是，大多数理智的语言不会这样做。