There are very, very few guarantees, but there are a few optimizations:
-
Extension methods that use indexed access, such as
ElementAt
,Skip
,Last
orLastOrDefault
, will check to see whether or not the underlying type implementsIList<T>
, so that you get O(1) access instead of O(N). -
The
Count
method checks for anICollection
implementation, so that this operation is O(1) instead of O(N). -
Distinct
,GroupBy
Join
, and I believe also the set-aggregation methods (Union
,Intersect
andExcept
) use hashing, so they should be close to O(N) instead of O(N²). -
Contains
checks for anICollection
implementation, so it may be O(1) if the underlying collection is also O(1), such as aHashSet<T>
, but this is depends on the actual data structure and is not guaranteed. Hash sets override theContains
method, that’s why they are O(1). -
OrderBy
methods use a stable quicksort, so they’re O(N log N) average case.
I think that covers most if not all of the built-in extension methods. There really are very few performance guarantees; Linq itself will try to take advantage of efficient data structures but it isn’t a free pass to write potentially inefficient code.