14

「Groovy2.0の新機能」を読みましたが、@CompileStaticをいつ使用するかについて少し混乱しています。この記事では@CompileStatic、Java7の動的な呼び出し部分を利用できなかった開発者向けにアノテーションが追加されたと述べています。

したがって、パフォーマンスの向上を求める開発者は、JDK 7で実行できない場合、Groovy 2.0で大きな変更は見られません。幸い、Groovy開発チームは、タイプチェックを許可することで、これらの開発者が他の利点の中でも興味深いパフォーマンスの向上を得ることができると考えました。静的にコンパイルされるコード。

私の質問は、JDK 7を使用していて、指示に従って--indyフラグを追加する場合@CompileStatic、パフォーマンスの向上を確認するために追加する必要がありますか？ このブログは私がそうすることを示唆していますが、彼がEclipse内でそれを行ったことを考えると、彼が正しくコンパイルしたかどうかはわかりません。

更新：フィボナッチコードのさまざまな順列を実行したときの統計は次のとおりです。

> groovy --indy FibBoth.groovy
..........Fib (non-static indy): 1994.465
..........Fib (static indy): 529.197

> groovy FibBoth.groovy       
..........Fib (non-static): 1212.788
..........Fib (static): 525.671

注：機能が独立していることを理解した今、この質問は少し混乱しているようです。質問の基本は、2つの機能が関連していると思わせたメモからの混乱にあるため、質問の文言を変更せず、違いを説明する受け​​入れられた回答を許可するのは理にかなっていると思います。

4

2 に答える 2

13

知られているように、indyバージョンは完全に動的なGroovyですが、JDK7のinvokedynamicのおかげで高速になります。@CompileStaticは、静的コンパイルを意味します。通常のGroovyよりも高速ですが、Groovyのサブセットのみをコンパイルでき、動作が少し異なります。特に、すべての動的機能は使用できなくなりました。したがって、動的機能を使用する場合は、indyが唯一のオプションです。あなたが静的な人であり、言語のごく一部しか使用しない場合は、@CompileStaticを使用できます。

フィボナッチは、invokedynamicが輝くことができるテストではありません。インディポートが常に優れているとは限りません。しかし、たとえばメタプログラミングで多くのことを行う場合は、インディの方が優れています。

最終的には用途に応じて決める必要があります

于 2013-02-19T14:08:13.500 に答える
5

要約すると、@CompileStaticはGroovyの動的ランタイム機能の一部を削除して速度を優先します。

したがって、理論的には：

  • JDK7は、invokedynamicのため、JDK6よりも高速である必要があります
  • @CompileStaticは、一部のオーバーヘッドと機能が削除されているため、Standardよりも高速である必要があります。

さまざまな機能がさまざまな程度に最適化されているため、それはあなたが何をしているかに大きく依存するという警告があります。

于 2013-02-21T07:47:06.780 に答える