使用查詢表達式而不是lambda表達式的要點是什麼？它不僅慢甚至更詳細的(see here)：查詢表達式與Lambda表達式
例（從上面的鏈接）：
QE: var products = from p in northwind.Products where p.Category.CategoryName == "Beverages" select p;
LE: var products = northwind.Products.Where(p => p.Category.CategoryName == "Beverages");
結果（從上面的鏈接）：
QE: 00:00:00.0019557, avg. 00:00:00.0004552
LE: 00:00:00.0000574, avg. 00:00:00.0000133
是否真的值得擁有34X倍速度較慢的代碼僅用於可讀性？
最後它們是一樣的。
您的文章測試出現難以置信的速度的原因是因爲推遲執行。該代碼實際上並沒有在他們正在計時的區域做任何事情。它只會在調用.ToList()時執行某些操作。或者強制對查詢（lambda或其他）進行評估的另一種方法。解析查詢很快（非常快，查看你提供的時間），但是當查詢得到評估時，它實際上是循環查詢數據的另一個野獸。
編輯：
我剛剛閱讀文章。根據作者的說法，您會注意到，for循環是所有3個循環中最慢的一個（查詢表達式，方法語法，for循環）。這是非常錯誤的。
基本for循環怎麼能上千次的λ慢？這只是沒有意義。循環是迭代數據的最基本的方式。拉姆達的做法比循環更加令人難以置信的進步是什麼？
......他們沒有。他們還沒有執行。看哪：延期執行。
謝謝你的回答，幫助了很多 – biox
感謝您的洞察。值得指出的是，在高需求應用中（即考慮500,000個併發用戶的情況），即使是「令人難以置信的快速」查詢也可能變得重要，所以在這種類型的級別上進行微觀優化是可以進行的良好習慣。 –
編譯器將查詢表達式轉換爲使用lambdas的查詢。這意味着這兩個樣本將編譯爲完全相同的代碼，所以不會有性能差異。
這意味着您鏈接到基準是非常錯誤的（並考慮它的其他錯誤，這並不令人吃驚），而且你應該基於可讀性兩種形式之間的決定。
可能無論哪個先發生，都需要更長時間才能生成由於緩存而導致的查詢。基準測試可能會顯示更快的lambda版本，如果你換了它們。 –
我想這可能已經在[這個問題]（http://stackoverflow.com/questions/3914611/comparision-linq-vs-lambda-expression），但沒有一個真正的結論已經討論過。 –
如果我可以告訴人們關於LINQ的一件事情，那就是：**查詢表達式的結果是*查詢***。這不是**執行查詢**的結果。你發現*寫出問題*比回答問題*要快得多，這並不奇怪。 –