有没有什么可告诉我们,毫秒或触发器中处理器的操作有多贵? 我会对“instanceof”,演员(我听说他们非常“昂贵”)感兴趣。
有关于此的一些研究吗?
答案 0 :(得分:8)
这将取决于您正在使用的JVM,并且即使在同一JVM中,许多操作的成本也会有所不同,具体取决于具体情况以及JIT执行了多少优化。
例如,Hotspot JIT仍然可以内联虚拟方法调用 - 只要它没有被其他任何东西覆盖。在使用服务器JIT的某些情况下,它可以仍然内联快速类型测试,最多可以使用几种类型。
基本上,JIT足够复杂,不太可能有一个有意义的通用答案。您应该以尽可能真实的方式对自己的具体情况进行基准测试。您应该通常编写具有简单和可读性的主要目标的代码 - 但定期测量性能。
答案 1 :(得分:6)
计数指令或周期可以让您对某些代码的性能有所了解的时间早已不复存在,这要归功于在各个级别的软件执行中发生的许多优化。
对于基于VM的语言来说,这是特别 true,其中JVM可以简单地跳过一些步骤,因为它知道它不是必需的。
例如,我前段时间在一篇文章(我将尝试查找并最终链接它)中读到这两种方法在成本上非常相同(在HotSpot JVM上,即):
public void frobnicate1(Object o) {
if (!(foo instanceof SomeClass)) {
throw new IllegalArgumentException("Oh Noes!");
}
frobnicateSomeClass((SomeClass) o);
}
public void frobnicate2(Object o) {
frobnicateSomeClass((SomeClass) o);
}
显然,第一种方法做得更多,但 JVM知道o
的类型已经在if
中检查过并且实际上可以跳过< / strong>稍后对演员表进行类型检查并使其成为无操作。
这个以及许多其他优化使计数“失败”或循环几乎无用。
一般来说,instanceof
支票相对便宜。在HotSpot JVM上,它归结为对象头中类型id的数字检查。
This classic article描述了为什么你应该“编写愚蠢的代码”。
2002年还有一篇文章描述了how instanceof
is optimized in the HotSpot JVM。
答案 2 :(得分:3)
一旦JVM预热,大多数操作都可以以纳秒(百万分之一毫秒)计算。当谈到昂贵的东西时,你通常不得不说它相对于另一种选择而言是昂贵的。在所有情况下,几乎不可能描述一些昂贵的东西。
通常,最重要的费用是您的时间(以及您团队中的其他开发人员)使用instanceof
在开发和代码支持时间上可能很昂贵,因为它通常表明设计不佳。使用适当的OOP技术通常是一个更好的主意。 instanceof
可能需要的10纳秒,通常是相对微不足道的。
答案 3 :(得分:1)
在CPU内部执行的特定操作的成本几乎从不与性能相关。如果性能不好,几乎总是因为IO(网络,磁盘)或代码效率低下。编写高效代码更多的是找到一种方法来减少操作的总量,而不是避免“昂贵”的操作(除了那些成本更高的数组,比如IO)。