java编译器优化

发布于 2024-08-24 19:51:48 字数 591 浏览 5 评论 0原文

Java 编译器是否足够聪明,可以通过从

Double average = new Double( totalTime / callCount ); 

for 循环中提取内容来优化下面的循环?

public double computeSD( Set values, int callCount, long totalTime ) {
  double diffs = 0.0d; 
  for( Iterator i=values.iterator(); i.hasNext(); ) {
    double value = ( ( Double )i.next() ).doubleValue(); 
    Double average = new Double( totalTime / callCount ); 
    diffs += ( value – average.doubleValue() ) * ( value – average.doubleValue() );
  } 
  double variance = diffs / callCount;
  return Math.sqrt( variance );
}

Is the Java compiler smart enough to optimize loop below, by extracting the

Double average = new Double( totalTime / callCount ); 

out of the for loop?

public double computeSD( Set values, int callCount, long totalTime ) {
  double diffs = 0.0d; 
  for( Iterator i=values.iterator(); i.hasNext(); ) {
    double value = ( ( Double )i.next() ).doubleValue(); 
    Double average = new Double( totalTime / callCount ); 
    diffs += ( value – average.doubleValue() ) * ( value – average.doubleValue() );
  } 
  double variance = diffs / callCount;
  return Math.sqrt( variance );
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

爱冒险 2024-08-31 19:51:48

没有什么可以阻止字节码编译器(java->字节码)执行优化。当我在赛门铁克工作时,他们做了一个 Java IDE,编译器编写人员确实考虑过对我们的编译器进行一些优化,但表示(外部世界)似乎没有人感兴趣,重点是即时 (JIT)与现代 Sun VM 中的 HotSpot 大致相同的编译器。

没有什么可以阻止字节码编译器执行优化,但我不知道有任何这样做。人们非常关注运行时优化,但这些优化在运行时几乎是隐藏的。

因此,源代码->字节码编译器可能不会优化它,但虚拟机可能会优化它。如果您使用的是 Android 之类的设备,那么它可能不会执行运行时优化。

Nothing prevents the bytecode compiler (java->bytecode) from performing optimizations. When I worked at Symantec, and they did a Java IDE, the compiler write did look into putting some optimizations into our compiler but said nobody (in the outside world) seemed to be interested and the focus was on the Just In Time (JIT) compiler that is roughly the same as HotSpot in modern Sun VMs.

There is nothing that prevents a bytecode compiler from performing optimizations, but I am not aware of any that do so. There is huge focus on runtime optimizations, but those are pretty much hidden at runtime.

So, the source->bytecode compiler probably does not optimize it but the VM probably does. If you are on something like an Android then it probably performs no runtime optimization.

忱杏 2024-08-31 19:51:48

Java 不会也不可能将其从循环中提取出来。
任何对“new”关键字的使用都会导致创建一个新对象。
您最好使用 Double.valueOf()

请参阅 Double.valueOf(double) 的 javadoc:

“返回表示指定 double 值的 Double 实例。如果不需要新的 Double 实例,则通常应优先使用此方法而不是构造函数 Double(double),因为此方法可能会产生明显更好的空间和通过缓存频繁请求的值来提高时间性能。”

如果使用此方法,它将每次返回相同的对象,从而减少创建的对象数量并提高性能。

但是,使用 valueOf 仍然不是您的答案!

valueOf 仍然是一个方法调用,并且方法调用不会得到优化。它将在循环的每次迭代中调用 valueOf。查看您的方法并计算方法调用次数。现在是6个,包括hasNextnew Double,类似于方法调用。这些每次都会发生,任何 java 优化都不会改变这一点。您最好进行重构以从循环中删除尽可能多的方法调用。

Java will not and can not extract it from the loop.
Any use of the 'new' keyword will always result in a new object being created.
You would be better off using Double.valueOf()

See the javadoc for Double.valueOf(double):

"Returns a Double instance representing the specified double value. If a new Double instance is not required, this method should generally be used in preference to the constructor Double(double), as this method is likely to yield significantly better space and time performance by caching frequently requested values."

If you used this method it would return the same object every time, thus reducing the number of objects created and increasing performance.

However, using valueOf is still not the answer for you!

valueOf is still a method call, and method calls do not get optimized away. It will call valueOf every iteration of the loop. Look through your method and count the method calls. Right now it is 6, including hasNext and new Double, which is similar to a method call. These will all happen every time, and no java optimization will change that. You are better off refactoring to remove as many method calls as possible from the loop.

妖妓 2024-08-31 19:51:48

如果您确实想确定,请查看此问题的答案 告诉您如何查看 JIT 编译器生成的本机代码。

If you really want to be sure, the answers to this question tell you how to see the native code that the JIT compiler produces.

云巢 2024-08-31 19:51:48

乍一看,这似乎是一个明显的优化,但我不这么认为,因为它涉及对象实例化。当然,它是不可变原始框类型的实例化,但这仍然不能保证没有副作用。

我认为当前任何编译器都无法对此进行优化。为了优化这一点,必须告诉编译器某些类具有特殊属性(考虑到将来情况可能会发生变化,这可能是一个危险的命题)。也就是说,必须告知编译器 API 的详细信息。这不能仅在语言层面进行优化。

但是,如果您使用 double ,则它更有可能被优化(例如使用 循环不变代码移动技术)。

This may seem like an obvious optimization at first, but I don't think so, since it involves object instantiation. Granted, it's an instantiation of an immutable primitive box type, but that still doesn't guarantee that there's no side effect.

I don't think any current compiler can optimize this. For this to be optimized, the compiler must be told that some classes have special properties (which can be a dangerous proposition given that things may change in the future). That is, the compiler must be told specifics of the API. This can not be optimized at the language-level alone.

If you use double, however, it's much more likely to be optimized (e.g. using the loop-invariant code motion technique).

软糖 2024-08-31 19:51:48

并不真地。编译器只是写出字节码。如果有什么东西优化了代码,那就是 Java 虚拟机,这可能取决于平台、实现和执行条件......

Not really. The compiler just writes out byte-code. If anything optimized the code, it'd be the Java Virtual machine and that probably depends on the platform, implementation and execution conditions...

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文