LINQ to Entites 4.0查詢默認編譯？

我剛剛開始每天都使用LINQ。我讀了很多有關L2E查詢應被編譯使用，以提高性能如下：LINQ to Entites 4.0查詢默認編譯？

CompiledQuery.Compile(query);

使用LINQ到實體4.0我跑了查詢10次未編譯，然後進行編譯，並取得了以下結果以秒爲單位：

// Sample Query 
from u in ctx.Users orderby u.Id, u.Username select u 

Uncompiled Compiled 
--------------------- 
0.295  0.2946174 
0.024  0.0220462 
0.008  0.0060126 
0.013  0.0210441 
0.007  0.010021 
0.011  0.010021 
0.008  0.0060126 
0.009  0.0070147 
0.008  0.0060126

正如您所看到的，從我的小測試中發現時間並沒有真正的巨大差異。第一次調用的時間較慢，然後兩者加速（意味着編譯/緩存）。任何人都可以提供對此的見解？

來源

2010-06-25 TheCloudlessSky

做了調查這個前一陣子和，阿法克（這絕對不是最終的）答案是否定的。如果我能找到一個明確的答案，我會在這裏給它，但假設沒有人會這樣做。 – Will 2010-06-25 18:57:15

那麼第一次評估查詢時發生了什麼？ – TheCloudlessSky 2010-06-25 19:20:01

據我所知，它大約有硬編碼的SQL查詢的嵌入參數使用命名參數SQL查詢同樣的好處：該系統可以識別它們都是一樣的，並使用相同的查詢計劃。例如，如果您只是簡單地將上面的表達式內聯，那麼如果您總是傳入相同的ctx.Users對象，那麼它可能會像編譯它一樣好。但是，如果你有幾個相同類型的用戶信息庫，並計劃於使用order by上所有的人，這將是一個好主意，一旦編譯查詢和使用參數進行訪問。

研究這個時，我看了一下在IL中如何形成一個LINQ查詢：每次調用它時，都會爲您的LINQ查詢中的每個子句創建一個新的Func<>委託。僅僅因爲這個原因，我認爲編譯一個查詢對你的系統來說會更好，只要內存崩潰。

來源

2010-06-26 02:13:29

是的，我意識到SQL服務器顯然是做一些查詢的緩存，因爲未編譯版本在第一次運行查詢時具有相同的性能問題。今天在我的家用機器上進行了更多的測試後，我發現平均編譯查詢在我的環境中運行速度快了0.001秒。這不是很多，但有趣的是沒有那麼多。 – TheCloudlessSky 2010-06-28 00:09:52

你可能不處置的環境。查詢會緩存在上下文中，但編譯它們可以讓您跨多個上下文使用它們。很難肯定地說，因爲你實際上並沒有顯示你的完整代碼。

來源

2010-06-25 20:32:43

不，它被包裹在一個被點擊的按鈕時所調用的方法內部的'using'聲明（我沒有跟我的代碼，但我知道一個事實，我處置它）。 – TheCloudlessSky 2010-06-26 01:46:35

然後，如果你想要一個答案，你將不得不張貼代碼。 – 2010-06-26 02:24:05

LINQ to Entites 4.0查詢默認編譯？

回答

相關問題