In particular, if you are querying over a large number of items in a collection or array, regardless of the item type, LINQ can be much slower than a typical foreach loop with the appropriate "if tests". I put together some sample code to test the performance of LINQ vs foreach loops over a large array of strings, and as well, over a large collection of integers. Let's look at the code and then the output and draw some conclusions: using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Diagnostics; namespace LINQPerformance { class LINQPerfTest { static string[] strArray; static string[] strTest; private const int number = 1000; //Change this number to size the Array public static void Main() { FillArrayWithGuids(); FindTenElements(); Console.WriteLine("Using For Each loop with Strings:"); UseForEachLoop(); Console.WriteLine("Using LINQ With Strings:"); UseLinq(); Console.WriteLine("Use Foreach with int:"); UseForeachWithIf(); Console.WriteLine("Use LINQ Where with int:"); UseLinqWhereQuery(); Console.ReadKey(); } private static void UseForEachLoop() { Stopwatch sw = new Stopwatch(); for (int i = 0; i < 10; i++) { sw.Start(); foreach (var item in strArray) { if (item == strTest[i]) { sw.Stop(); Console.Write(" Item found in {0} ticks\n", sw.ElapsedTicks.ToString()); break; } } } } private static void UseLinq() { Stopwatch sw = new Stopwatch(); for (int i = 0; i < 10; i++) { sw.Start(); var qry = from x in strArray where x == strTest[i] select x; foreach (var item in qry) { } sw.Stop(); Console.Write(" Item found in {0} ticks\n", sw.ElapsedTicks.ToString()); } } // Initialize Array and retrieve 10 elements for comparison private static void FillArrayWithGuids() { //Fill the string Array with GUIDs strArray = new string[number * 10]; for (int i = 0; i < number * 10; i++) { strArray[i] = System.Guid.NewGuid().ToString(); } } private static void FindTenElements() { //Find 10 elements from the big array for comparison //We are finding the elements from different locations to see if that has any affect on performance strTest = new string[10]; strTest[0] = strArray[0 * number]; strTest[1] = strArray[1 * number]; strTest[2] = strArray[2 * number]; strTest[3] = strArray[3 * number]; strTest[4] = strArray[4 * number]; strTest[5] = strArray[5 * number]; strTest[6] = strArray[6 * number]; strTest[7] = strArray[7 * number]; strTest[8] = strArray[8 * number]; strTest[9] = strArray[9 * number]; } // Work with List<int> performing standard foreach with "if test" private static void UseForeachWithIf() { int ctr = 0; List<int> ints = new List<int>(); for (var i = 0; i < 10000000; i++) { ints.Add(i); } Stopwatch sw = Stopwatch.StartNew(); foreach (var item in ints) { if (item % 2 == 0) ctr++; } sw.Stop(); Console.Write(" Foreach took {0} ticks\n", sw.ElapsedTicks.ToString()); } // Work with List<int> performing LINQ Where test private static void UseLinqWhereQuery() { int ctr = 0; List<int> ints = new List<int>(); for (var i = 0; i < 10000000; i++) { ints.Add(i); } Stopwatch sw = Stopwatch.StartNew(); foreach (var item in ints.Where( x=>x%2==0)) { ctr++; } sw.Stop(); Console.Write(" LINQ Where took {0} ticks\n", sw.ElapsedTicks.ToString()); } } } Here is sample Console Output: As can be seen, in both the string and the int cases, LINQ with a where clause or query is significantly slower than a standard foreach loop with "if tests" in the loop -- so much so that it behooves developers to be aware of this impediment whenever attempting to do iterations over an array or collection. LINQ queries to find strings in a large collection or array can be from 2 to as much as 32 times slower than using a standard foreach loop, depending on how the LINQ query is constructed. If you are going to use LINQ, it is important to test. There are many ways to write a LINQ query. For example, examine the two queries below: var qry = from x in strArray where x == strTest[i] select x; var qry = strArray.First(x => x == strTest[i]); Both queries will return the same result in this demo , but one of them, if used in the demo code above, is significantly faster. Do you know which one? Where raw performance is an issue, I would be inclined not to use LINQ unless there are other overriding reasons to do so. You can download the sample test solution here.