如果我也使用Java 7，我应该使用Groovy的@CompileStatic

Question

我已经阅读了"What's new in Groovy 2.0"，我对何时使用@CompileStatic感到有些困惑。文章提到为那些无法利用Java7的调用动态部分的开发人员添加了@CompileStatic注释。

  

因此，如果他们无法在JDK 7上运行，那么寻求性能改进的开发人员不会看到Groovy 2.0中的太多变化。幸运的是，Groovy开发团队认为这些开发人员可以通过以下方式获得有趣的性能提升。允许静态编译类型检查代码。

我的问题是，如果我正在使用JDK 7并按照说明添加--indy标志，我是否需要添加@CompileStatic以查看某些性能提升？ This blog表示我愿意，但我不确定他是否正确编译，因为他是在Eclipse中完成的。

更新：以下是运行Fibonacci代码的不同排列时的统计信息。

> 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

注意：由于我了解这些功能是独立的，因此这个问题似乎有点混乱。由于问题的基础是围绕着使我认为两个特征相关的注释的混淆，我认为不改变问题措辞并允许解释差异的接受答案是有道理的。

Answer 1

indy版本是完全动态的Groovy，因为它已知，只有JDK 7 invokedynamic才能更快。 @CompileStatic表示静态编译​​。虽然比正常的Groovy更快，但它只能编译Groovy的一个子集并且行为有点不同。特别是所有动态功能都不再可用。因此，如果您想使用动态功能，那么indy是唯一的选择。如果你是一个静态的人并且只使用该语言的一小部分，那么可以使用@CompileStatic。

Fibonacci不是一个invokedynamic可以发光的测试。 indy端口并不总是更好。但是如果你做了很多元编程，那么indy会更好。

你必须根据你的用法决定

Answer 2

为了简化它，@ CompileStatic删除了一些Groovy动态运行时功能以支持速度。

所以，理论上：

• 由于invokedynamic
，JDK7应该比JDK6更快
• @CompileStatic应该比Standard快，因为删除了一些开销和功能。

所有这些都需要注意，这在很大程度上取决于你正在做什么，因为各种功能都在不同程度上进行了优化。