我們知道linq是ado.net堆棧頂層的一個層。這是非常好的功能,並使數據庫查詢好得多,但linq是一個額外的層,因此它增加了一些開銷,將linq查詢轉換爲sql查詢並映射回ado.net中的結果,而我們直接編寫sql查詢。LINQ何時勝過ado.net
我的問題是什麼時候linq執行比使用正常的ado.net方法更快。
我們知道linq是ado.net堆棧頂層的一個層。這是非常好的功能,並使數據庫查詢好得多,但linq是一個額外的層,因此它增加了一些開銷,將linq查詢轉換爲sql查詢並映射回ado.net中的結果,而我們直接編寫sql查詢。LINQ何時勝過ado.net
我的問題是什麼時候linq執行比使用正常的ado.net方法更快。
你總是能夠擊敗LINQ支持一個存儲過程從ADO訪問的數據庫,然後直接作用或(如果你必須處理對象)用來構造一個只有大量數據的對象手頭任務需要。
但是,LINQ讓我們能夠快速創建一個查詢,通過返回匿名對象來返回該任務所需的信息。
要對每個查詢的自定義代碼做同樣的事情,需要不停止處理其他層的ADO(以多種方式填充)和/或創建大量重複其大部分功能的對象,但不分享代碼。
因此,雖然它可以在性能上被打敗,但在這種情況下,如果沒有很多的重複代碼,它不能被打敗。它可以擊敗更自然的方法(返回具有膨脹的實體對象,我們不會使用)的性能。
最後,即使在沒有獲勝的情況下,它的寫作速度仍然會更快,而且操作更加清晰,這與實體的定義方式有關(後者是我非常喜歡的主要原因)它)。
當在原始SQL中編寫所有這些查詢以及管理所有其他翻譯等時所節省的時間使您可以花更多時間找到性能瓶頸。
LINQ不是性能優於SQL的。這是關於使代碼更簡單和更清晰,所以你可以專注於更重要的方面。有時可能有些時候,查詢的自然LINQ表達式會以比你自己想出的更快的SQL結束 - 雖然也有很多次會發生相反的情況。您仍應該查看正在生成的SQL,並相應地對其進行分析。
+1:它並不總是關於更高效的代碼。這是關於什麼是更有效的業務。丟失幾個時鐘週期,同時節省大量的開發人員時間是LINQ經常「勝過」ADO .NET的一種方式。 (並不總是,但經常。) – David 2010-11-26 21:39:55
當程序員不知道ado.net的複雜性:) – basarat 2010-11-26 21:29:29