我正在使用bash脚本、node.js和C的组合为ARM系统开发几个应用程序。我在开发时使用注释来跟踪代码中发生的事情或停用实际代码。
我的经验是，每个额外的内存指针和处理器周期都会减慢系统的速度。
为了优化，我应该删除生产代码中的所有注释吗？还是不值得担心？
正如其他答案所提到的，c(或任何其他编译的)代码都没有区别。
这可以证明如下：
$ touch 0comments.c
$ time gcc -c -o 0comments.o 0comments.c
real 0m0.022s
user 0m0.009s
sys 0m0.009s
$ seq -f '/* This is comment %g */' 1000000 > 1000000comments.c
$ time gcc -c -o 1000000comments.o 1000000comments.c
real 0m0.163s
user 0m0.135s
sys 0m0.021s
$ cmp 0comments.o 1000000comments.o
$
生成两个.c文件，一个为空，另一个包含1000000条注释，然后进行编译。对生成的对象进行比较，不会显示任何差异。
请注意，编译时间确实增加了，尽管每个注释的编译时间非常小，所以除非在最极端的情况下，否则不应该是一个问题。
使用bash，我无法在循环中测量注释的任何显著差异：
$ time for i in {0..1000000}; do
> :
> done
real 0m4.054s
user 0m4.006s
sys 0m0.049s
$ time for i in {0..1000000}; do
> :
> # This is a comment
> done
real 0m4.047s
user 0m3.999s
sys 0m0.048s
$
尽管可能存在更严格的测试用例。
每当bash必须解析任何类型的循环时，它都需要在执行之前解析整个循环(这样它就知道将输出重定向到哪里，等等)。我怀疑注释在解析过程中被删除了，所以它们不会在每次循环迭代中被重新解析。
但是，如果注释不在任何类型的循环中(或者可能是函数)，那么解析时间很小，但可以测量：
$ seq -f "# This is comment %g" 1000000 > 1000000comments
$ chmod +x 1000000comments
$ time ./1000000comments
real 0m1.675s
user 0m1.468s
sys 0m0.207s
$ touch 0comments
$ chmod +x 0comments
$ time ./0comments
real 0m0.001s
user 0m0.000s
sys 0m0.001s
$
不知道node.js，尽管与任何解释语言类似，除了在最极端的情况下，它可能几乎没有区别。
底线是-请不要删除您的评论-它们存在是有充分理由的。如果你删除了它们，你代码的未来维护者(可能包括你)将永远诅咒你的名字
没有必要删除注释。当编译器运行时，会删除额外的内容，包括注释。即使您使用的是解释语言，注释也不会使用CPU周期，因为它们不是可执行代码，尽管它们可能会增加极其微不足道的解析时间。
关键是，不要担心。为了在编译或执行时间上产生可靠的可测量的差异，您必须有绝对荒谬的注释数量。
在C中，在预处理过程中，每个注释都将被一个空格字符替换，我们可以通过起草C99标准章节5.1.1.2翻译阶段第3段来看到这一点，其中写道：
[…]每个注释都由一个空格字符替换。保留新行字符。除了换行符之外，每个空白字符的非空序列是保留还是由一个空格字符替换，这是实现定义的。
因此注释不应对C产生影响。
在C的情况下，注释作为预处理阶段的一部分被剥离，并且不占用可执行文件中的空间；它们对运行时性能几乎没有影响。
不确定bash或node.js；我希望差异可以忽略到无关紧要的程度，但唯一可以确定的方法是运行自己的基准测试，比较注释代码和未注释代码的性能。但是，只有当注释的代码不符合硬性能要求时，才应该这样做。
编辑
请不要使用注释来停用代码；这种做法将导致维护方面的麻烦(已经做到了，得到了多种尺寸和颜色的t恤)。在C的情况下，您可以使用预处理器来控制代码的包含：
#if defined(SOME_MACRO)
/**
* code that may or may not be active
*/
#endif
否则，如果代码不再是活动的，将其删除，并使用版本控制工具(CVS、git等)来跟踪这些更改。