原文來自Alexandra Rusina在CSharpFAQ的：Does the “LINQ to Objects” provider have built-in performance optimization?

?

讓我們從基礎開始，可能會重復一些你已經知道的信息。在LINQ性能優化中最重要的一點，當然是延遲執行。那便意味著當你聲明一個變量并分配給它一個查詢字符串，其查詢字符串并沒有立即執行。

?

//?查詢沒有執行。

var?query =?from?item?in?storage?select?item;

??

變量query現在存儲著命令，查詢執行被延遲直到你從變量query請求獲取數據。這通常發生在如下幾種情況：foreach循環，或當你調用一個聚集函數像Min,Max和Average，或當你使用ToList或ToArray方法緩存該查詢結果。

?

// foreach循環。

foreach?(var?item?in?query)

????Console.WriteLine(item);

?

// Count函數。

int?total = query.Count();

?

// ToArray方法。

var?cachedQuery = query.ToArray();

?

現在讓我們來看看幕后究竟發生了什么。在查詢執行的時候是否有什么編譯器級的優化發生？答案是yes。然而，這里有個陷阱。從現在起我們將只討論使用“LINQ to Objects”提供程序對IEnumerable和IEnumerable<T>集合的查詢。對于其他LINQ提供程序，包括LINQ to SQL和LINQ to XML，可能應用的是不同的優化規則。

?

注意：人們常常認為，由于延遲執行，執行第一次查詢需要花費更長時間。然而，在LINQ to Objects中，第一次執行和之后的每一次并沒有差別。其他LINQ提供程序的規則可能不同（比如，這里可能有些會進行緩存），但你需要參考特定的提供程序的詳細文檔。

?

?LINQ to Objects查詢在下面這些情況下會做優化：

?

• 一些方法調用會被優化，如果數據源實現了一個必要的接口。下面表格列出了這些優化。

??

LINQ方法	優化
Cast	如果數據源已經對給定的類型T實現接口IEnumerable<T>，則會直接返回數據序列而不需要轉換。
Contains	如果數據源實現了接口ICollection或ICollection<T>，其接口的相應的方法會被使用。
Count
ElementAt	如果數據源實現了接口IList或IList<T>，接口的Count方法和索引器會被使用。
ElementAtOrDefault
First
FirstOrDefault
Last
LastOrDefault
Single
SingleOrDefault

?

??

• 如果連續的一個或多個Select操作后面跟著連續的一個或多個Where操作，查詢只會創建一個IEnumerable或IEnumerable<T>對象而不會創建中間對象。

考慮下面的查詢：

?

var?query =?from?item?in?storage

????????????where?item.Category =?"Food"

????????????where?item.Price < 100

????????????select?item;

?

在這里，查詢只會創建一個IEnumerable對象。

??

• 如果你查詢一個數組或List，接口IEnumerable或IEnumerable<T>不會在foreach循環中使用枚舉器。相反，在使用前會創建一個數組或List的簡單for循環，元素被直接訪問。

?

此外，where操作符實現了簡單的if語句，所以不會有中間的枚舉器產生。

?

再次說明，其他LINQ提供程序可能擁有它們自己的性能優化規則。但上面的規則應該能給你一些怎么使用LINQ to Objects的意見。

轉載于:https://www.cnblogs.com/tianfan/archive/2010/03/03/does-the-linq-to-objects-provider-have-built-in-performance-optimization.html

總結

以上是生活随笔為你收集整理的[翻译]“LINQ to Objects”提供程序是否内置性能优化？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。