我是一名高级开发人员，所以在我看来这是一个愚蠢的问题。我的答案应该是否定的，或者什么？不！！！
但我昨天在开会，我正在解释一些 PMD 结果。当我们遇到“方法名太长”的问题时，我开始解释，客户说：好吧，记住方法名太长会影响性能，程序运行速度会变慢。
我说：不，你错了，只是一个干净的代码规则，获得一个好的代码很重要，但与性能无关，字节码相似，名称不同。
但是客户，还有一些在会议上争论的人，对此很确定。他们有一些项目，方法名称过长是性能不佳的原因。
我唯一的想法是一些自省或反射的东西与此有关，但除此之外，我确信，或者我认为我是肯定的，方法名称长度对性能没有任何影响。
对此有何想法或建议？
可以说它会占用更多的内存和存储空间 - 例如，包含具有大量方法名称的类的 jar 文件将大于具有短类名称的 jar 文件。
但是，性能上的任何差异都不太可能引起注意。我认为几乎可以肯定的是，他们将长方法名称归咎于性能不佳的项目实际上被误诊了。这不像是第一次发生。
当然，从这种情况中解脱出来的最好方法是提供证据——如果性能很重要，你应该对性能进行测试。使用长方法名运行这些测试，然后将它们重构为短方法名并重新运行测试。如果有显着差异，我会感到非常惊讶。
方法名称不仅与反射相关，而且在类加载期间也相关，当然在这两种情况下，方法名称很长意味着在某种程度上 CPU 要做的事情更多。但是，由于方法名称的长度甚至很实用（即不是数千个字符长），我绝对可以肯定，与在反射或类加载期间必须完成的其他事情相比，这不可能是重要的。
但是客户，还有一些在会议上争论的人，对此很确定。他们有一些项目，方法名称过长是性能不佳的原因。
这听起来像是一个完全的猜测被视为事实。这只是一些人对性能的普遍疯狂的一个例子。 即使他们碰巧是对的，这也是一个完全的猜测。
每个程序都有通过改变某些东西来提高性能的空间。猜测不会告诉你那些东西是什么。
如果做同样事情的两个程序有不同的性能，那只意味着它们已经被优化到不同的程度。你的挑战是解释这一点。
如果缩短类名和成员名，则会对启动时间产生积极影响。为此，可以使用字节码收缩器。
例如，yguard (LGPL) 可以收缩代码。它还允许您出于调试目的对堆栈跟踪进行去混淆处理。
出于性能原因手动分配短类和成员名称当然是一个可怕的想法。
我不知道为什么它可能会显着影响性能，除非您通过反射自己提取方法名称，然后在 UI 上呈现它们。显然情况并非如此。所以我很困惑。您确定您的客户没有将方法名称与文件名混淆，或者他是否正在考虑一些非常古老的编程语言不支持超长方法名称的情况？根据那个人的年龄，他们的判断对于计算机科学家来说绝对是荒谬的。如果他们能用事实证明他们的观点，他们不妨将其提交给 ACM、Oracle/Sun 或 MIT 以验证他们的发现。
我认为函数名称的长度对性能的影响如下：
当一个黑盒（lib 文件、app）连接到其他黑盒（lib 文件、app）时，它使用头文件中的函数名作为标识。所以我认为名称的长度会影响性能。