2015-06-30 17 views
2

我正在使用F# Code Quotations來生成可執行的.NET庫,通過LINQ expression treesFSharp.Compiler.Services使用鍵入與未鍵入的F#代碼引用的運行時性能影響是什麼?

我可以創作/製作的AST的使用類型報價需要的,但我有一個特定的區域掙扎的表達能夠解決多種類型 - 因此正在考慮非類型化代碼的報價。

我從this SO question從安全的角度來看類型表達式的優點,但我主要關心的是運行時性能。

  1. 如果您的表達式可以解析爲多種類型,它是元編程「代碼氣味」嗎?

  2. 請問這有什麼區別的運行時性能(.NET)如果我使用類型與類型化的報價/表情

+2

與大多數關於性能的問題一樣:*取決於*。你有沒有試圖測量差異? –

+0

在我測試的一個(很多潛在的)應用程序中,我沒有看到性能的差異 - 這讓我感到驚訝。我的問題是:我應該感到驚訝嗎?如果無類型表達式可以在生成/編譯時計算出它們的類型,那麼性能可能相當。 – Sam

回答

1

如果你只是比較類型化和類型化的F#報價(即, ExprExpr<'T>類型),則不會有任何實際差異。鍵入引用的優點是,他們可以(在一定程度上)在編譯時檢查你正在構建正確的引用,但底層表示實際上是完全相同的。

如果你看看definition of Expr<'T> in the source code,你可以看到它實際上只是一個超過Expr(它有一個額外的類型參數,但代表完全相同的東西)的輕量級包裝。

如果您有興趣編譯代碼更普遍然後這裏有幾個要點:

  • F#報價轉換爲LINQ表達式樹等有一個額外的步驟。而且,這比F#編譯器生成的代碼慢。

  • 使用LINQ表達式樹比使用F#語句困難,所以在這種方法和引用之間進行選擇是非常棘手的。 F#編譯器服務使您可以直接訪問編譯器,但最好記錄的API是編譯字符串(仍然,這可能是更好的選擇,因爲它會生成更快的代碼)。

+0

謝謝。所以這聽起來像*我如何編譯它們會產生效果,並且'打字與打字'完全沒有關係。我一直在看的兩個庫是:(1)FSharp.Quotations.Evaluator(使用LINQ表達式樹),比內置的LINQ編譯器提供更好的性能;(2)使用舊版本的FSharp.Compiler的QuotationCompiler。服務 - 看起來這個長期以來最好......然後......? – Sam

相關問題