C++ 如果在源代码中使用较短的名称，程序是否更高效？

或者名称较短的函数是否比名称较长的函数更有效？为什么

---

就我个人而言，我想它会更有效率，但效率不足以让我们关心它，只是猜测而已

没有性能差异，因为这些名称在机器级别并不重要。编译器将处理掉这些名称，这样就不会对程序产生任何影响

---

函数名可能会转换为标签（这不会影响运行时性能），变量名可能会被寄存器引用或堆栈操作替换（两者都与您使用的名称无关）。在这个级别上，操作系统使用（并跳转到）内存地址，而不是名称。

更长的符号名称可能会略微降低编译速度，但符号长度对执行时间没有影响

解释器的某些实现可能会受到符号名长度的影响，但大多数现代解释器不会受到影响：解释器通常会执行“编译”步骤，将符号名从其他处理中删除

---

我用的是1972年的跑步基本功。用户手册建议使用短符号名称以提高速度和节省内存。

在哪些方面有效？运行时使用的内存、编译时使用的内存、运行时执行的计算、编译时执行的计算、可执行文件的大小，还是其他什么

更长的标识符在编译时需要更多的计算和内存。此外，调试可执行文件包含一些符号，因此较长的标识符可能会影响调试可执行文件的大小

---

就运行时计算和内存使用而言，不，标识符的长度除了上述差异的间接影响之外没有任何影响。

这将取决于您所针对的平台，假设您的意思是发行二进制文件的运行时性能

---

例如，在Symbian操作系统上，DLL中的函数是通过序号查找的，因此名称永远不是二进制文件的一部分。因此答案是否定的，它没有更高的效率，因为它没有任何区别，因为它从未出现在目标图像中。

回答问题的字母：长名称的函数将与短名称的函数一样有效，除非它递归地调用自己（在极少数情况下）

回答问题的实质（当然是猜测）：在现代计算机上运行的绝大多数现代语言的源代码中使用长标识符的代码，即使是那些传统上被认为是“解释的”代码，其效率也不会低于使用短标识符的代码

总的答案是，除了（好的，有些人为的）进一步的例外：

黑白 编译语言：在编译期间，符号被添加到符号表中。符号表的大小和复杂性会影响编译步骤的运行时，但不会影响程序自身的运行时

解释语言：符号被添加到某种解释时间字典中，定位符号所需的时间通常以O（n）的速率变化，其中n是符号长度

灰色的影子 编译语言：对于一个可能的异常，采取动态加载和内省。 例如，在C on*nix中，可以调用

dlopen（）

函数打开共享对象，然后调用

dlsym（）

函数按名称查找该对象中的数据或子程序。这将导致按名称搜索对象的符号表。如果这是程序的主要部分，那么相对于对象的长度，程序可能最终具有O（n）复杂度。然而，在实践中，像这样加载对象只是为了在初始化时加载模块化单元或插件，并且查找实际上不会发生太多。当然，您自己的程序中符号的长度仍然不会影响运行时

解释语言：绝大多数现代解释语言都会执行一些严重的优化和标记化，因此最终，引用长标识符或短标识符可能是100%等效的。散列、长度限制等都简化了事情。解析更长的标识符需要花费额外的时间（在现代计算机上，有时需要几微秒），根据语言的不同，每次运行程序时都需要解析，但每次运行最多只能解析一次。除非你做了大量的

eval

s，或者进行了大量的内省，否则你不应该看到问题。即使如此，在Python的情况下，内省也是基于

dict

，并且

dict

使用哈希来定位键，因此运行时随着符号的数量而不是长度的增加而增加

---

但是它是编译的还是解释的？你看得越多，现在使用的纯解释语言就越少。注释中提到了Python，但Python将源代码编译成字节码，并在内部通过标记引用标识符，而不是它们的全名。JavaScript引擎做的事情非常相似，这取决于特定的实现。甚至（大部分）80年代的8位基础程序也执行了标记化步骤，这样程序就不会以文本形式存储在内存中（这节省了内存和CPU周期，在3MHz、64KB的计算机上并没有大量供应），而是以易于解释的中间形式存储。变量名将被放入字典中，并使用标记（通常是地址）来引用它们。列出该程序将有效地取消标记以供显示。

可能使用python、ruby等解释语言。。。但我怀疑它是否值得注意（尽管从未测试过）。在编辑源代码时，更短的函数名更有效。但是Intellisense会进一步缩短输入长名称的时间@正如你注意到的智能感知帮助打字，但也考虑人