I come from Java programming and switching to C# programming I discovered the extreme powerful of LINQ.
In my recent implementation I noticed that I use it (expecially LINQ to Objects) very often in my code to avoid foreach loops, to search elements in lists and for similar tasks.
Now I'm wondering if there is some performance disadvantage in massively use Linq to Objects...
Linq is slower than native C# loops.
C# is slower than C++.
C++ is slower than assembly.
Assembly is slower than designing your own custom microprocessor.
So you should always design your own custom microprocessor instead of using Linq.....
Is there a performance hit? Probably, but you won't know how much until you actually measure it. It may be small enough that it won't be significant and you can spend the time you would have spent avoiding Linq tackling the parts of the application that do benefit by optimization.
Bottom line is - build your app using the libraries and frameworks that make you the most productive, then optimize from there. You may find out that the slowest part of your app isn't the Linq code at all, so you'd be optimizing the wrong thing if you forbade it just because it might be slower than rolling your own loops.
To answer your question objectively, LINQ makes heavy use of delegates and iterators, which has the overhead of instantiations (delegates and iterators) and method calls (delegate invocation and MoveNext() on iterators). Now, a foreach (on a List<T>) will have the overhead of the iterator, but not the overhead of delegates. So it's expected that LINQ will be slower here than a foreach.
Likewise, iterating through the list using the [i] indexer is expected to be faster still because it also doesn't have the overhead of the iterator. Even faster is not using a List<T> but an array. But even that has the overhead of array bounds checks (the bit that throws an IndexOutOfRangeException if you try to go outside array bounds) and that can be avoided by using raw memory access through pointers, or by simply iterating the entire list (for(var i = 0; i < array.Length; i++) { Console.WriteLine(array[i]); } won't have bounds checks because the compiler can prove this loop will never go out of bounds).
Those are the varying degrees of overhead that the various ways of iteration bring with them. Do those overheads matter? If you're doing 10,000 x 10,000 matrix multiplication, then yes. Otherwise, probably not unless you've measured it to be (which is a tired old answer, but no less valid).
However, aside from those facts it also matters how you use them. Say you want a list of customers who were born after 1980 from a larger pile of customers and do further processing on them. Without LINQ, you be would pretty much forced to foreach the original customer list and create an intermediate list that you put the customers who were born after 1980 into. With LINQ, you won't need the intermediate list which saves quite a lot of overhead (creating the list, calling Add on it, resizing it several times most likely as it grows) and is likely to be faster. And it's certainly more memory efficient, as the customers born after 1980 are 'streamed' in one by one without the intermediate list taking up memory. With LINQ, you can potentially process an infinitely long sequence.
Another performance reason to use LINQ is that parallelization of certain operations becomes trivial with the AsParallel() call at the end of a query.
So to answer your question if there's a performance disadvantage to using LINQ:
It depends.
With any abstraction where you loose control and have to depend on implementations where you are not aware of the underlying code there is a tendency to have slower performance (because LINQ has to be generic and cannot be fully optimized for one type of object at the expense of another). However how much depends on your situation. For example if your application is hit millions of times per day and you need absolute performance then using LINQ to entities for database queries is probably not a great idea, you may want to do performance optimizations on your SQL queries that LINQ will not allow you to do. But if your application is used as part of an enterprise application where the number of users is relatively small then you're probably ok with using LINQ heavily. So my answer is yes it's going to be slower, but it may not matter because of your situation.
Broadly speaking LINQ offers no performance benefits, but some implementations of it might. If you want performant code then you still need to have a broad awareness of the algorithmic time complexity of each LINQ query.
E.g. a common scenario I've seen is to perform a WHERE clause over a list for a specific value, which will cause a scan of the items in the list, which will have O(n) complexity. Such an operation can of course be achieved with O(1) complexity if you maintain a hash table (e.g. Dictionary<K,V>) to perform the lookups against.
