代码长度会影响性能吗？答案

【问题标题】：Does code length impact on performance?代码长度会影响性能吗？
【发布时间】：2016-12-01 11:25:31
【问题描述】：

我以下面的例子来说明例子，但请注意它可以是任何其他任务。

for (int i =0; i< 1000; i++){     
  String a= "world";
  Log.d("hello",a);
}

对比

String a="";
a="world";
Log.d("hello",a);

String a="";
a="world";
Log.d("hello",a);

String a="";    
a="world";
Log.d("hello",a);

String a="";
a="world";
Log.d("hello",a);

String a="";    
a="world";
Log.d("hello",a);
...
//1000 times

让我们忽略可读性和代码质量，只考虑编译程序的性能。那么哪个更好呢？

【问题讨论】：

综合答案是：视情况而定。
是，但不能与 IO 相比。
如果您想知道，请测试一下。将微优化留给编译器和运行时。不要像这样复制和粘贴代码，因为您认为它的性能更好。除此之外，实践中的性能差异很可能并不重要。
非常容易出错，如何在滚动代码时轻松验证是否有 1000 个日志项？你甚至可能达到方法大小限制stackoverflow.com/questions/17422480/…
令人惊讶的是，刚学会编写一些代码的人如此担心他们的代码速度，即使他们正在编写的那种代码通常非常琐碎，而且并不真正即使它需要两倍的时间也很重要。这就像开始建造一座摩天大楼并花费数小时思考应该在顶部放置什么样的天线。

标签： java performance

【解决方案1】：

唯一的答案：这个根本不重要。

我的意思是：可读性和良好的设计等方面非常更值得您花时间。

当且仅当您设法设计出出色的应用程序时；并且您已经遇到了性能问题，您将不得不研究这个特定的问题；好吧，那么研究它会有好处。但我有 99.9% 的把握：你现在还不是。从这个意义上说：你是在浪费你的时间在这些想法上！

换句话说：尤其是在“JVM 堆栈”中，有很多东西会对性能产生微妙或不那么微妙的影响。比如：有很多选项会影响垃圾收集的内部工作以及即时编译器正在做什么。与手动展开循环代码相比，这会以更显着的方式影响正在运行的应用程序的“性能”。

郑重声明：许多基准测试实验表明，如果您向其提供“正常”代码，JIT 确实可以做到最好。含义：Oracle JIT 旨在为您提供“正常”输入的“最佳结果”。但是，一旦您开始摆弄您的 java 代码，以便以某种方式创建“优化”代码……您的更改可能会使 JIT 更好地完成困难。

因此：请忘记此类微优化。如果你花同样多的时间学习“好的 OO 设计”，也许还有“通用的 Java 性能主题”……你会从中收获更多！

【讨论】：

【解决方案2】：

那么哪个更好呢？

第一个，因为它实际上可以编译（第二个有错字）。非编译代码绝对是性能最低的代码。

还有第一个，因为尽管您说“忽略可读性和代码质量”，但可读性几乎总是比性能更重要。可读性当然是你在编写代码之前首先应该做到的。

第一个，因为 JIT 会为你展开循环，它确定它在运行它的特定 JVM 上具有更好的性能，对于运行代码的特定数据（我假设你不要只是喜欢一遍又一遍地用相同的消息填充你的日志）。

不要试图猜测 JIT 将应用的优化。自己应用优化可能会使性能变差，因为它会使 JIT 更难优化代码。编写清晰、可维护的代码，让 JVM 发挥它的魔力。

【讨论】：

【解决方案3】：

取决于编程语言。编译器负责以这样一种方式压缩您的代码，以避免在低级别重复调用。使用 java-script 等语言的面向对象编程处于相对较高的水平，因此编译可能需要一些时间才能运行。

因此，根据您的问题的假设进行简要总结，唯一的影响是整体文件大小和编译时间。

【讨论】：

这个问题纯粹是关于 Java 的。它没有使用任何其他语言或与语言无关的标签。

【解决方案4】：

您所做的称为“循环展开”。

检查：https://en.wikipedia.org/wiki/Loop_unrolling

如果使用适当的优化级别编译，这是编译器将执行的优化之一。

在我看来，您的第二个选项应该比第一个选项运行得更快。因为在第一个选项中，代码必须增加循环计数器，检查循环条件并做出适当的分支决定。如果存在分支错误预测，则分支本身可能会很昂贵。这是因为在分支预测错误时，CPU 必须清除所有管道并重新启动指令。检查：https://en.wikipedia.org/wiki/Branch_misprediction

【讨论】：