过时的Java优化提示

Question

过时的Java优化提示

Dan*_*Dan 42 java optimization performance

有许多性能提示被Java编译器淘汰,尤其是Profile-guided优化.例如,这些平台提供的优化可以极大地(根据来源)降低虚拟函数调用的成本.VM还能够进行方法内联,循环展开等.

你现在使用的其他性能优化技术有哪些,但实际上已经被更现代的JVM中的优化机制淘汰了？

Answer 1

Eug*_*hov 23

方法和方法参数的最终修饰符对性能没有任何帮助.

此外,Java HotSpot wiki可以很好地概述HotSpot使用的优化以及如何在Java代码中有效地使用它们.

我没有在方法参数或方法变量上使用final来优化任何东西,我将它用作编码实践,因此开发人员可以看到这个值确实没有改变.任何优化都是第二位的. (6认同)
方法(或类的那些)上的`final`不向JIT提供任何信息.但是,方法参数的`final`可以很好地提供有用的优化提示(类似于声明为final的局部变量).但最终,使用final的原因是强制不变性 - 这是一种设计时特性,使代码更易于维护.任何优化好处都需要a)只担心是否存在实际性能问题,并且b)进行详尽测试以确保它确实产生了影响. (4认同)
我使用final来确保一个类的不变性.通常作为私人最终字段.我也用它来确保我不改变传递参数的值/引用.换句话说,我只是将它用于正确而不是优化. (4认同)
很好的链接,但它似乎并没有解雇`final`.它说"最终"是暗示内联.我认为有些情况下final修饰符会向编译器保证它的值不能在循环中改变,即使该循环调用其他方法并超出当前范围. (2认同)
实际上,参数上的`final`通常没有任何区别(编译器真的可以看到你是否分配给它而Java没有通过引用传递变量 - 对象通过引用引用,但保存它们的变量不是' t)*但*它确实意味着该参数可以与内部类或匿名类一起使用.如果有意义,请使用,否则不要. (2认同)

Answer 2

Pau*_*lin 20

人们用String a = "this" + var1 + " is " + var2;StringBuilder或StringBuffer的多次调用替换.它实际上已经在幕后使用StringBuilder.

哦,我认为它会相当于`String a = new StringBuilder("this").append(var1).append("is").append(var2).toString();`？ (3认同)
这个*unauthoriative*来源http://www.rgagnon.com/javadetails/java-0129.html建议保罗对单个StringBuilder是正确的,但是说StringBuilder的默认容量可能太短(奇怪,这将是微不足道的对于花时间使用StringBuffer的编译器,在使用之前不会费心计算容量) (3认同)
在一行上进行字符串连接时,使用StrinBuilder不会添加任何内容.但是,替换它:`String a ="this"+ var1; a + ="is"+ var2;`使用StringBuilder仍然有效.(至少这是我上次检查时: - /) (3认同)
@Devon,我认为你是对的,因为在多行上执行它会涉及创建一堆不同的String对象. (2认同)

Answer 3

kha*_*hik 16

在开始性能优化之前,有必要定义时间/内存权衡.这就是我如何为我的内存/时间关键应用程序(重复上面的一些答案,完成):

规则#1永远不要在开发的早期阶段进行性能优化.如果你真的不需要它,永远不要这样做.如果决定这样做,那么:
使用profiler查找瓶颈,查看源代码以找出瓶颈的原因;
选择适当的数据结构,最适合定义的时间/内存权衡;
选择合适的算法(例如迭代与递归等);
如果你真的不需要,请避免使用java库中的同步对象;
避免显式/隐式地创建新对象;
当且仅当您确定它们不符合您的要求时,覆盖/重新实现java附带的数据类型/算法.
使用小型独立测试来测试所选算法/数据结构的性能.

这些提示并不是真的很有用.我的意思是,这是一个很好的建议,但你没有回答这个问题. (2认同)

Answer 4

Wil*_*ill 8

2001年,我为J2ME手机制作了应用程序.这是砖的大小.并且非常接近砖的计算能力.

让Java应用程序在其上运行可接受,需要尽可能以程序方式编写它们.此外,非常大的性能改进是捕获ArrayIndexOutOfBoundsException向量中的所有项目的退出for循环.考虑一下!

即使在Android上,在阵列中的所有项目都有"快速"循环,并且"慢速"编写相同的东西,如dalvik VM内部的Google IO视频中所述.

但是,在回答你的问题时,我会说最近必须对这种事情进行微观优化是非常不寻常的,而且我还期望在JIT VM上(甚至是新的Android 2.2 VM,它会增加JIT)这些优化都没有实际意义.2001年,这款手机以33MHz的速度运行KVM解释器.现在它运行dalvik--一个比KVM快得多的VM - 在500MHz到1500MHz之间,具有更快的ARM架构(更好的处理器,甚至允许时钟速度增益),L1等和JIT到来.

我们还不熟悉Java中的直接像素操作 - 无论是在手机上还是在带有i7的桌面上 - 因此Java仍然没有那么快的正常日常代码. 这是一篇有趣的博客,声称一位专家表示,对于一些繁重的CPU任务,Java占C++速度的80%; 我持怀疑态度,我编写了图像处理代码,我看到Java和native之间存在一个数量级的像素循环.也许我错过了一些技巧......？:d

归档时间：	15 年，1 月前
查看次数：	18459 次
最近记录：	9 年，7 月前