我总是（好好试试）评论我的代码。我已将配置我的服务器以在发送前删除这些注释/额外空格。最好不要在实时系统代码（Javascript / php）中发表评论，从而减少这种开销或删除或解释？
如果是这样，我怎么能吃蛋糕呢？
答案 0 :(得分：20)
对于PHP，它没有任何区别。您的PHP代码不会发送到浏览器。
对于JavaScript，建议您缩小代码。这通过更改变量名称，删除空格以及删除所有注释来减小其大小。有几个online tools用于执行此操作，它通常可在IDE中使用。
无论您做什么，请将您的代码留在您工作的位置。不要从PHP中删除注释，也不要手动缩小JS。
答案 1 :(得分：5)
虽然一般的假设是让PHP咀嚼评论导致 没有可衡量的差异 ，但最好还是检查一下，不是吗？
（注意：根据常识，我们期望纯粹的请求处理，权限管理，流程控制，调度，委派，启动PHP运行时环境，管理各种缓存，摆弄资产文件，整体磁盘和网络I / O等等，哦，BTW，还执行代码，所有这些都很可能比任何大量的评论都要多。）
所以我给了它一个非常简单的去，只是为了瞬间感受它。
预测＆＃34;评论影响＆＃34;为了像neutrinos一样难以察觉，我故意在一个轻微的病态设置之后，试图使差异可以衡量，但仍然不是过于不切实际。
我创建了两个文件。一个没有注释，只有~100个字节，直到点，no-comments.php：
<?php
function task() {
++$GLOBALS;
echo "[$GLOBALS] Lorem ipsum dolor sit amet cosectetur...\n";
}
另一个，~60K（仅限于与堆管理相关的迷信的64K以下），comments.php：
<?php
/* ... some 30K comments ... */
// OK, that's something, but how about:
/* ... same 30K comments again ... (Phantomjs changelog, for the curious of you. :) ) */
// Finally, do something:
function task() {
++$GLOBALS; // Comments are cheap, so let me tell you how much I enjoyed this instead of properly declaring a counter. :)
echo "[$GLOBALS] Lorem ipsum with a lot of comments...\n";
}
注意：这当然很可能实际上测试文件大小影响，而不仅仅是评论，但这始终是＆＃的固有部分34;评论（非）问题＆＃34;无论如何，我还想先某事。也许即使这已经无法衡量了，对吧？
然后，一般的想法是以各种方式循环task()，在同一个PHP进程中只有一点（或根本没有），并且来自外部，通过单独的执行，强制重新分析，这是本实验中唯一有趣的部分。
为了获得最快的结果，我做了一些 shell运行：
#!/bin/bash
for (( i = 0; i < 1000; i++ ))
do
php comments.php # <-- and another batch with "no-comments.php"
done
但事实证明这是不可靠的，因为增加循环次数会导致执行时间出现无法解释和不成比例的变化。我换了一个PHP跑步者，跑得更顺利：
#!/usr/bin/php
<?php
$t1 = microtime(true);
for ($i = 0; $i < 1000; ++$i ) {
system("php comments.php"); // <-- and with "no-comments.php"
}
$t2 = microtime(true);
echo "Time: ", $t2 - $t1
对于 HTTP运行，我添加了此index.php：
<?php
$GLOBALS = 0; // innovative use of a dull language feature ;)
$t1 = microtime(true);
require_once (isset($_GET['no']) ? 'no-' : '') . 'comments.php';
// Played a bit with looping here, but ended up leaving it out.
// for ($i = 0; $i < 3; ++$i) {
// task();
// echo '<br>';
// }
$t2 = microtime(true);
echo "<hr>Time: ", number_format($t2 - $t1, 10);
注意：首先，不幸的是，我启用了PHP的Zend Opcache，浪费了大量时间来试图理解结果......; -o然后我禁用了缓存，当然，重复网络测试（only）。
主机只是vanilla Debian，Apache2有一些PHP5（我猜它的FPM - 甚至不打算检查，因为它应该与测试主题正交（如果不是这样，请纠正我。）实际上甚至可以通过减少不相关的PHP启动开销来掩盖微小的注释解析时间来帮助揭示差异。）
运行PHP-cli的速度非常慢，所以我很快就感到无聊，因为这两个变种只有十几个循环的1000次迭代。 （结果以秒为单位。）
<强>注释：
44.2015209198
39.710990905762
42.374881982803
36.29861998558
44.764121055603
38.85772395134
42.627450942993
38.342661142349
48.539611816406
39.784120082855
50.34646987915
47.782819032669
36.974604845047
45.692447900772
平均：42.592717
没有评论：
45.617978811264
43.397685050964
46.341667175293
44.246716976166
40.348230838776
43.048954963684
38.57627081871
50.429704189301
41.811543226242
35.755078077316
53.086957931519
31.751699924469
48.388355970383
49.540207862854
平均：43.738647
正如你所看到的那样，它都是垃圾......但如果我们忽略环境波动，结论就是使用更多评论，它会让你的脚本更快！ ：）
（从ab输出中切除了一些噪音。）
<强>注释：
ab -qd -n 10000 'http://.../comments/?yes'
Server Software: Apache/2.4.10
Concurrency Level: 1
Time taken for tests: 3.158 seconds
Complete requests: 10000
Failed requests: 0
Non-2xx responses: 10000
Total transferred: 7120000 bytes
HTML transferred: 4620000 bytes
Requests per second: 3166.12 [#/sec] (mean)
Time per request: 0.316 [ms] (mean)
Transfer rate: 2201.45 [Kbytes/sec] received
没有评论：
ab -qd -n 10000 'http://.../comments/?no'
Server Software: Apache/2.4.10
Concurrency Level: 1
Time taken for tests: 3.367 seconds
Complete requests: 10000
Failed requests: 0
Non-2xx responses: 10000
Total transferred: 7120000 bytes
HTML transferred: 4620000 bytes
Requests per second: 2969.95 [#/sec] (mean)
Time per request: 0.337 [ms] (mean)
Transfer rate: 2065.04 [Kbytes/sec] received
哇！ ：-o就像shell运行一样！ :)好吧，不相信我的眼睛，我重复了几次，直到它有意义...... :)看到了吗？这里：
Benchmarking ...<"NO COMMENTS">... (be patient).....done
Time taken for tests: 2.912 seconds
Total transferred: 7120000 bytes
HTML transferred: 4620000 bytes
Requests per second: 3433.87 [#/sec] (mean)
Time per request: 0.291 [ms] (mean)
Transfer rate: 2387.61 [Kbytes/sec] received
（顺便说一句，不要问我，为什么非2xx的回复。他们通过网络可以200分。）
然后，迭代次数增加十倍：
<强>注释：
Time taken for tests: 32.499 seconds
Requests per second: 3077.04 [#/sec] (mean)
Time per request: 0.325 [ms] (mean)
Transfer rate: 2139.51 [Kbytes/sec] received
没有评论：
Time taken for tests: 28.257 seconds
Requests per second: 3538.92 [#/sec] (mean)
Time per request: 0.283 [ms] (mean)
Transfer rate: 2460.66 [Kbytes/sec] received
好吧，我还做了一些，我只能在记录中严格告诉你这个无评论的结果：
Time taken for tests: 37.399 seconds
Requests per second: 2673.84 [#/sec] (mean)
Time per request: 0.374 [ms] (mean)
Transfer rate: 1859.15 [Kbytes/sec] received
好的，在意识到我打开了缓存之后，我从PHP-FPM配置中注释掉了扩展（确实，这就是这里运行的内容），重新启动了服务，检查了phpinfo() ，并收集了新的结果：
<强>注释：
Time taken for tests: 34.756 seconds
Requests per second: 2877.23 [#/sec] (mean)
Time per request: 0.348 [ms] (mean)
Transfer rate: 2000.58 [Kbytes/sec] received
再次：
Time taken for tests: 31.170 seconds
Requests per second: 3208.24 [#/sec] (mean)
Time per request: 0.312 [ms] (mean)
Transfer rate: 2230.73 [Kbytes/sec] received
没有评论：
Time taken for tests: 30.060 seconds
Requests per second: 3326.70 [#/sec] (mean)
Time per request: 0.301 [ms] (mean)
Transfer rate: 2313.10 [Kbytes/sec] received
再次：
Time taken for tests: 32.990 seconds
Requests per second: 3031.23 [#/sec] (mean)
Time per request: 0.330 [ms] (mean)
Transfer rate: 2107.65 [Kbytes/sec] received
好。正如您所看到的，基本上是： 没有差异 来自opcache开/关状态！评论开/关之间（除了微小的暗示，但看到了波动......）！ ：-o
所以...最后，数字！嗯，无用的垃圾，事实上，但至少不仅仅是宗教的猜测。感到困惑的是混淆数据的合理原因而不是缺乏它！ ：）
现在，在我确实浪费了足够多的时间之后，回答这个古老的问题＆＃34;评论费用多少＆＃34;仍然是一个谜。
随着中微子（令人难以置信）多年来被发现，我们可能会开始感到尴尬。有人最终会带来突破并最终检测到PHP评论的影响吗？没人知道......
答案 2 :(得分：2)
如果您想提高PHP应用程序的性能，那么您应该使用像XCache或APC这样的字节码缓存。
这样服务器就不必在每个请求上解析PHP代码。当然，您的服务器必须支持这种扩展。
至于删除评论：我不确定这会产生很大的不同（除了你的意见很大）。
答案 3 :(得分：1)
是的，它有影响！毫无疑问。
每次PHP必须解释不以某种方式缓存的代码时，如果需要从磁盘读取更多数据，I / O操作需要更长的时间。
解释本身（如果不以这种或那种方式缓存）也需要更长的时间。
性能损失很大程度上取决于正在使用的文件系统和缓存。在您的具体情况下，它可能不那么重要。
在我们编写的Web框架中，当我们打包分发文件以便在生产环境中使用时，我们会专门删除所有注释，以确保LIVE应用程序不受我们的惩罚许多注释（通常，我们＆＃34; String＆＃34;例程的源文件在删除注释之前约占169Kb，并且仅在处理后为46Kb）。
我们已经放弃了尝试衡量真正的惩罚，因为无法应对各种环境，文件系统和缓存机制。因此，我们决定以两种方式分发我们的代码：评论和没有评论。
答案 4 :(得分：0)
你可以在你的php文件中有评论，但我不建议在Javascript中使用大量的评论。
PHP正在服务器端运行，因此服务器可以通过注释轻松处理php文件。
答案 5 :(得分：0)
它在JavaScript中有所不同，因为你想向浏览器发送较少的数据，但在php中它并不重要。注释没有性能损失，因为编译器会忽略它们。 对于Javascript，您可能希望获得正常注释的.js文件的副本，但它们始终通过minifier运行并创建yourscript-min.js用于生产。
当您需要更改脚本时，只需更改正常脚本，然后重新创建缩小版本。仅在生产中使用缩小版本。
同样，对于php而言，它无关紧要，仅适用于Javascript和html文件。
答案 6 :(得分：0)
它更好地删除所有js文件注释，甚至使用minifier工具。减少js文件大小会减少客户端上的页面加载时间（因为他需要下载）并且花费更少的带宽（关于谁付钱）。
答案 7 :(得分：0)
如果您的系统上配置了某些内容来动态“压缩”您的javascript，那么这样做会有一些问题。我实际上已经使用.htaccess实现了这一点，你可以获得巨大的性能提升，并在服务器本身上注释了代码。
我使用谷歌的闭包工具（服务器上的jar文件）并运行关闭，如果PHP中的md5_file（）出现不同。
接下来，我使用etags为该文件分配标签。我也缓存该文件。
当etag匹配时，我还会返回304未修改的内容。如果没有，那么我返回新文件并更新用户etag。这很关键，因为如果你返回200 / OK，你会再次传回整个文件。
这里的关键是，如果你动态压缩，你就会失去性能，因为你总是在压缩和运行PHP代码。如果你花时间去做，你可以正确实现它。我个人喜欢这种技术，因为我可以在不发送非缩小版本的情况下修补实时服务器代码。此技术的“第一次运行”的性能很慢，但后续用户下拉服务器上的缓存文件，然后我返回304后未修改的文件。你必须在压缩PHP文件中做所有这些魔术。
我在这里也提到了.htaccess，因为我在那里使用了一个重写规则，并告诉网站哪些文件要压缩，哪些不要压缩。例如mylibrary.jsc告诉我的网站用关闭来压缩它。 yourlibrary.js允许我在那里有其他.js文件并按需压缩。
答案 8 :(得分：0)
很明显，这可以对巨大的流量产生影响，但在大多数设置上绝对可以忽略不计。考虑一个你喜欢1mil的网站。并发连接和Web应用程序（即像Joomla这样有许多php文件和大部分注释的CMS）请求每个连接那些几个评论很多和缩进的php文件。将minifing应用程序的每个php文件都有所不同吗？我想如果你没有启用任何类型的缓存，那肯定会。它只是基本的I / O内容，文件越小，加载/处理它所需的内存就越少。