LinQ to SQL and non-linq ways to implement group performance comparison

A data sheet with 476550 of data. Use one of these fields to group, and then sort by that field. This requirement is implemented using LINQ to SQL and Non-linq, and then look at the performance comparison.

LinQ to

 from inch context. Part_partgroup p by P.functiongroup into Groupedps  groupedps.keySelect Groupedps

LinQ on-the-loop for group

Non-linq

 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);} 

non-linq to group

From

var New sorteddictionary<long?, ilist<part_part>> ();

As you can see, the type of field used for sorting is long?. Take a look at the execution time first.

	LinQ to	Non-linq
First time	1:6.698	6.707
Second time	1:7.404	1.426
Third time	1:7.127	1.486
Forth time	1:6.952	1.425

It is obvious that the performance of LINQ is very low under this scenario. Adjust the code, this time using a partdescription grouping of type string. Test, the results are as follows.

	LinQ to	Non-linq
First time	>30min	8.738
Second time	>30min	4.201
Third time	>30min	4.173
Forth time	>30min	4.176

With this scenario, the NON-LINQ is a time-consuming increase, and the LinQ-mode is a horrible one. Even after 30 minutes of hard waiting for the result, the test procedure was terminated early.

It can be seen that LINQ brings a loss of performance while providing simple wind and excellent readability. Take a look at a description of LINQ performance issues from the LINQ in Action.

There is 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 is around to percent.

So, can you use LINQ in the future? Take a look at the description in the LinQ in Action.

Do is afraid to the use of LINQ, but it wisely. For simple operations that is 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 is overkill. For queries that is not executed several times per second, you can probably use LINQ to Objects safely. A query that's executed only once in a non-time-critical context won ' t make a big difference if it takes milliseconds To execute instead of 10.

LinQ to SQL and non-linq ways to implement group performance comparison