2013-02-07 55 views
13

我已閱讀了"What's new in Groovy 2.0",我對使用@CompileStatic時有點困惑。該文章提到@CompileStatic註釋是針對無法利用Java7的調用動態部分的開發人員添加的。我是否應該使用Groovy的@CompileStatic(如果我也使用Java 7)

所以開發商在尋找性能的改善不會看到太大的變化在Groovy 2.0,如果他們不能在JDK 7上運行幸運的是,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 

注意:這個問題似乎有點混淆,因爲我明白這些功能是獨立的。由於這個問題的基礎是圍繞着使我認爲兩個特徵是相關的筆記的混淆,所以我認爲不改變問題措辭並允許接受的解釋差異的答案是有意義的。

回答

12

indy版本是完全動態的Groovy,據瞭解,由於JDK 7 invokedynamic,速度更快。 @CompileStatic表示靜態編譯​​。雖然比正常的Groovy快,但它只能編譯Groovy的一個子集,而且行爲有點不同。尤其是所有的動態功能都不再可用。所以如果你想使用動態功能,那麼indy是唯一的選擇。如果你是一個靜態人物,只使用一小部分語言,那麼可以使用@CompileStatic。

斐波納契不是一個invokedynamic可以發光的測試。 indy港並不總是更好。但是如果你用元編程做了很多例子,那麼indy會更好。

你必須根據最終

+0

很好的答案。我從發佈的措辭中遺漏的部分是它們是獨立的功能。所以,即使使用Java 7和-indy,CompileStatic也可以提供一個性能提升(只要代碼實際上可以由編譯器進行類型檢查)。我們用indy和CompileStatic與斐波那契做了不同排列的快速測試,結果如下: – Scott

5

熬下來您的使用情況來決定,@CompileStatic消除有利於速度的一些Groovy的動態運行時功能。

所以,從理論上講:

  • JDK7應該是快於JDK6,因爲invokedynamic
  • @CompileStatic比標準應該是更快,因爲一些開銷和功能將被刪除。

所有的警告,它將在很大程度上取決於你在做什麼,因爲各種功能都優化到不同程度。

相關問題