如果在源代码中使用较短的名称,程序是否更有效?

13 c++ performance

或者是具有较短名称的函数比具有较长名称的相同函数更有效?为什么或者为什么不?

我个人认为它会更有效但效率不高,无法让我们关心它,只是猜测.

Ole*_*ksi 27

没有性能差异,因为这些名称在机器级别无关紧要.编译器将处理这些名称,因此它根本不会对您的程序产生影响.

函数名称可能会变成标签(不会影响运行时性能),变量名称可能会被寄存器引用或堆栈操作取代(两者都与您使用的名称无关).在这个级别,操作系统正在使用(并跳转到)内存地址,而不是名称.

  • @Oleksi对于动态链接的部分,这可能确实非常慢.例如,Windows DLL允许按名称寻址函数,这需要在DLL的名称表中进行二进制搜索.因此,限制因素实际上是DLL中符号的总数,而不是单个名称的长度.Windows在缓存这些查找方面做得非常好.在其他系统中,可能会出现类似的问题.使用静态库,所有这些都在编译时解决. (6认同)

wal*_*lyk 13

较长的符号名称可能会稍微减慢编译速度,但符号长度对执行时间没有影响.

解释器的某些实现可能受符号名称长度的影响,但不是大多数现代解释器的实现:它们通常执行"编译"步骤,该步骤从其他处理中除去符号名称.

我使用了一运行解释BASIC 的1972 HP桌面计算机.用户手册建议使用短符号名称来提高速度并节省内存.


Ale*_*ios 5

要回答问题的字母:具有长名称的函数将与具有短名称的函数完全一样有效,除非它以递归方式调用自身(在极少数情况下).

回答问题的精神(当然是猜测它):在现代计算机上运行的绝大多数现代语言中使用源代码中的长标识符的代码,即使那些通常被认为是"解释"的代码也不会低于使用代码的代码.短标识符.

一般的答案,进一步下来(好吧,有点人为)例外:

黑,白

编译语言:在编译期间将符号添加到符号表中.符号表大小和复杂性会影响编译步骤的运行时间,但不会影响程序自身的运行时间.

解释语言:符号被添加到某种解释时间字典中,并且定位符号所需的时间通常以O(n)速率变化,其中n是符号长度.

灰色的影子

编译语言:对于一个可能的例外,采取动态加载和内省.例如,在C on*nix中,您可以调用该dlopen()函数来打开共享对象,然后调用该dlsym()函数以按名称查找该对象中数据或子程序.这会导致按名称搜索对象的符号表.如果这是程序的主要部分,那么您的程序可能最终在对象的长度方面具有O(n)复杂性.但是,在实践中,加载这样的对象只是为了在初始化时加载模块化单元或插件,并且查找并不真正发生.当然,您自己程序中符号的长度仍然不会影响运行时.

解释语言:绝大多数现代解释语言都会执行一些严格的优化和标记,因此最后,引用长标识符或短标识符可能是100%等效的.散列,长度限制等都可以简化事情.它需要花费额外的时间(有时在微秒,在现​​代计算机上)来解析更长的标识符,并且根据语言,这可以在每次运行程序时完成,但每个程序运行最多一次.除非你做了很多evals或大量的内省,否则你不应该看到问题.即便如此,在Python的情况下,内省是dict基于的,并且dict使用散列来定位键,因此运行时随着符号数量而不是它们的长度而增加.

但它是编译还是解释?你看的越多,你今天使用的纯解释语言就越少.注释中提到了Python,但是Python将源代码编译为字节码,并在内部通过标记引用标识符,而不是它们的全名.JavaScript引擎执行非常类似的操作,具体取决于特定的实现.甚至(大多数)八十年代的8位BASIC执行了标记化步骤,因此程序没有以文本形式存储在内存中(这节省了内存和CPU周期,而不是3 MHz,64 KB计算机上的大量供应) ,但在中间形式容易解释.变量名称将放在字典中,并且用于引用它们的标记(通常是地址).列出该程序将有效地对其进行去标记以进行显示.