LinQ to SQL 及 non-LinQ方式實現Group的Performance對比

擁有476550數據的一張數據表。使用其中的某個字段分組，然后按該字段進行排序。該需求分別使用LinQ to SQL和non-LinQ的方式實現，然后來看一下performance對比。

LinQ way

from p in context.Part_Partgroup p by p.FunctionGroup into groupedPsorderby groupedPs.Keyselect groupedPs

non-LinQ way

var results = new SortedDictionary<long?, IList<Part_Part>>();foreach (var p in context.Part_Part){    IList<Part_Part> groupedValue = null;    if (!results.TryGetValue(p.FunctionGroup, out groupedValue))    {        groupedValue = new List<Part_Part>();        results[p.FunctionGroup] = groupedValue;    }    groupedValue.Add(p);}        

從

var results = new SortedDictionary<long?, IList<Part_Part>>();

可以看出，用來排序的字段類型為long?。先看一下執行時間。

明顯可以看出在這個scenario下，LinQ的performance極低。調整代碼，這次使用類型為string的PartDescription分組。測試，結果如下。

這個scenario下，non-LinQ way耗時有所增加，而LinQ way更是慘不忍睹。甚至在苦苦的等了30分鐘不見結果后，提早結束了測試程序。

可見，LinQ在帶來簡潔風和極佳可讀性的同時，也帶來了性能的損耗。看一段來自于《LinQ in Action》中，關于LinQ性能問題的描述。

There are no surPRises. LINQ does not come for free. LINQ queries cause additional work, object creations, and pressure on the garbage collector. The additional cost of using LINQ can vary a lot depending on the query. It can be as low as 5 percent, but can sometimes be around 500 percent.

既如此，以后還能不能愉快的使用LinQ呢？再來看一段《LinQ in Action》中的描述。

Do not be afraid to use LINQ, but use it wisely. For simple Operations that are executed extensively in your code, you may consider using the traditional alternatives. For simple filter or search operations, you can stick to the methods offered by List<T> and arrays, such as FindAll, ForEach, Find, ConvertAll, or TrueForAll. Of course, you can continue to use the classic for and foreach statements wherever LINQ would be overkill. For queries that are not executed several times per second, you can probably use LINQ to Objects safely. A query that is executed only once in a non-time-critical context won't make a big difference if it takes 60 milliseconds to execute instead of 10.