或者，名称较短的函数比具有较长名称的相同函数更有效吗？为什么或为什么不呢？
我个人认为它会更有效但效率不高，无法让我们关心它，只是猜测。
答案 0 :(得分：27)
没有性能差异，因为这些名称在机器级别无关紧要。编译器将处理这些名称，因此它根本不会对您的程序产生影响。
函数名称可能会变成标签（不会影响运行时性能），变量名称可能会被寄存器引用或堆栈操作取代（两者都与您使用的名称无关）。在这个级别，操作系统正在使用（并跳转到）内存地址，而不是名称。
答案 1 :(得分：13)
较长的符号名称可能会稍微减慢编译速度，但符号长度对执行时间没有影响。
解释器的某些实现可能会受到符号名称长度的影响，但不会影响大多数现代解释器：它们通常会执行“编译”步骤，从其他处理中删除符号名称。
我使用了1972 HP desktop computer运行解释的BASIC。用户手册建议使用短符号名称来提高速度并节省内存。
答案 2 :(得分：5)
要回答问题的字母：具有长名称的函数与具有短名称的函数完全一样有效，除非它以递归方式调用自身（在极少数情况下）。
回答问题的精神（当然是猜测）：代码在现代计算机上运行的绝大多数现代语言中使用源代码中的长标识符，甚至是那些通常被认为是'解释'的效率不会低于具有短标识符的代码。
一般答案，（好吧，有点做作）例外进一步向下：
编译语言：在编译期间，符号会添加到符号表中。符号表大小和复杂性会影响 compiliation 步骤的运行时间，但不影响程序自身的运行时。
解释语言：符号被添加到某种解释时字典中，找到符号所需的时间通常会以O（n）速率变化，其中n是符号长度。
编译语言：，对于一个可能的例外，采取动态加载和内省。
例如，在C on * nix中，您可以调用dlopen()函数打开共享对象，然后调用dlsym()函数以按名称查找该对象中的数据或子程序>。这会导致按名称搜索对象的符号表。如果这是程序的主要部分，那么您的程序可能最终在对象的长度方面具有O（n）复杂性。但是，在实践中，加载这样的对象只是为了在初始化时加载模块化单元或插件，并且查找并不真正发生。当然，您自己的程序中符号的长度仍然不会影响运行时。
解释语言：绝大多数现代解释语言都会执行一些严格的优化和标记，因此最后，引用长标识符或短标识符可能是100％等效的。散列，长度限制等都可以简化事情。它需要额外的时间（有时在微秒，在现代计算机上）来解析更长的标识符，并且根据语言，这可以在每次运行程序时完成，但每个程序运行最多一次 。除非你做了很多eval或大量的内省，否则你不应该看到问题。即便如此，在Python的情况下，内省是基于dict的，而dict使用散列来定位键，因此运行时随符号数而增加，而不是长度
但它是编译还是解释？你看的越多，你今天使用的纯解释语言就越少。注释中提到了Python，但是Python将源代码编译为字节码，并在内部通过标记引用标识符，而不是它们的全名。 JavaScript引擎执行非常类似的操作，具体取决于特定的实现。甚至（大多数）八十年代的8位BASIC执行了标记化步骤，因此程序没有以文本形式存储在内存中（这节省了内存和CPU周期，而不是3 MHz，64 KB计算机上的大量供应） ，但在中间形式容易解释。变量名称将放在字典中，并且用于引用它们的标记（通常是地址）。列出该程序将有效地对其进行去标记以进行显示。
答案 3 :(得分：1)
高效的方面是什么？在运行时使用的内存，在编译时使用的内存，在运行时执行的计算，在编译时执行的计算，在可执行文件中执行的计算，还是其他什么？
更长的标识符在编译时需要更多的计算和内存。此外，调试可执行文件包含一些符号，因此较长的标识符可能会影响调试可执行文件的大小。
就运行时计算和内存使用而言，除了前面提到的差异的间接影响之外，标识符的长度没有影响。
答案 4 :(得分：1)
这取决于您所定位的平台，假设您的意思是发布二进制文件的运行时性能。
例如，在DLL中的Symbian OS函数通过序数查找，因此名称永远不会是二进制文件的一部分。因此答案是否定的，因为它从未出现在目标图像中，所以效率并不高，因为它没有任何区别。