9

JSR-292がGroovyのパフォーマンスにどの程度影響するかを示す見積もりはありますか？

4

4 に答える 4

4

JDK7ではパフォーマンス特性が常に変化するため、invokedynamicは実際には複雑な話です。Groovyをindyに移植している間、私は本当に、本当にJavaに近く、約1.5倍になりました。ただし、catchExceptionGuardを使用する必要があります。これにより、パフォーマンスが3〜4倍に低下します。そのガードを使用する必要を回避する方法を調査する必要があります。そのためには、Groovy2.2の既存のコードを壊さなければならないかもしれません。とにかく、上記のように、invokeMethodフォールバックのガードは必要ありません。GroovyRuntimeExceptionsには、他の例外が含まれている可能性があり、ラップを解除するか、他のことを行う必要があります。したがって、理論的に可能なパフォーマンスは、既存のメソッドのJavaとJavaの半分の速度の間にあるようです。invokeMethodの呼び出しのパフォーマンスは、まったく別の話です。

さらに必要な場合は、Groovy2.0の@CompileStaticを使用してください。

于 2013-01-16T13:40:00.007 に答える
3

まだベンチマークはないと思います。誰かがそれを実行するまで、私たちは推測することしかできません...

この件に関するこの投稿は興味深いと 思うかもしれません。

于 2010-01-06T06:14:01.880 に答える
2

一般的には約10〜50倍速くなります。

http://www.mail-archive.com/mlvm-dev@openjdk.java.net/msg00819.html

于 2010-01-06T13:57:43.580 に答える
0

Groovyにどれだけ適用できるかわかりません。私がよく覚えているなら、Groovyにはいくつかのフォールバックがあります（例えば、invokeMethodメソッド）。フォールバックをinvokedynamicで単純に使用することはできないと思います。

ただし、いくつかの方法があります。

  • メソッドが見つからない場合にスローされる例外をキャッチします。残念ながら、スタックトレースがどこからスローされたのかわからないため、スタックトレースを分析する必要があります。これは、invokeMethodコールバックによって処理されるかどうかに関係なく、存在しないメソッドを呼び出すときに大幅に遅くなる可能性があります。
  • Groovy++を見てください。いくつかの制約を満たす場合は、静的型付けを使用できます。このような場合、これらのフォールバックを許可しない「厳密な動的モード」に切り替えることができる可能性があります。
于 2011-04-30T09:02:48.287 に答える