Optimise First, Last, FirstOrDefault & LastOrDefault for OrderedEnumerable

[JonHanna]

Fixes #2400

If you only want the first or last element of an ordered enumerable, you do
not need to O‎(n log n) (worse case, O(n²) but rare) operation of sorting
the entire set in O(n) space, but can instead to an O(n) retrieval of just
that element in O(1) space.

[stephentoub]

cc: @VSadov

[MarcelGosselin]

Typo in interface name IOrderedPartit_i_onable

[JonHanna]

Removing this from here was mainly to be able to have both Iterator and IPartition share the same interface-path to ToArray. Some Iterators have a ToArray that ends up going through Buffer twice, so just removing them and letting Buffer do what it would do anyway is a side-effect benefit.

[JonHanna]

After some further changes, checks, and squashing, the state of this PR is:

The following operations have changed time complexity on the results of an OrderBy(), OrderBy().ThenBy(), etc:

Operation	Old Time Complexity	New Time Complexity
First() Last() FirstOrDefault() LastOrDefault()	O(n log n) Best O(n log n) Average O(n²) Worse O(n) Space Compexity	Θ(n) O(1) Space Complexity
ElementAt() ElementAtDefault()	O(n log n) Best O(n log n) Average O(n²) Worse	O(n) Best O(n) Average O(n²) Worse

ElementAt() and ElementAtDefault() use a Θ(n) fast-path when possible (when it turns out to be the first or last element), which is sometimes O(1) in space and sometimes O(n).

There is also some work to make the worse-case less likely to be hit.

When .Skip(j).Take(k) is called on such results (cases of just Skip() or just Take() can be considered the same, but with j or k being 0), then the complexity of obtaining the results for any subsquent operation (or to enumerate) is changed thus:

(k here is the number of results actually taken, rather than asked for, so if there are 5 items and you try to take 7, k is 5)

Old Time Complexity	New Time Complexity
O(n log n) Best O(n log n) Average O(n²) Worse	O(n + k log k) Best O(n + k log k) Average O(n²) Worse

Once the results are prepared, enumerating (directly or indirectly) is also reduced from Θ(j + k) to Θ(k).

These ordered Skip/Take results also have the following changes to their complexity:

Operation	Old Time Complexity	New Time Complexity
First() Last()† FirstOrDefault() LastOrDefault()†	O(n log n) Best O(n log n) Average O(n²) Worse	O(n) Best O(n) Average O(n²) Worse
ElementAt()† ElementAtDefault()†	O(n log n) Best O(n log n) Average O(n²) Worse	O(n) Best O(n) Average O(n²) Worse

Those marked † also had a O(n) component that was completely removed, so the lower-order costs are also improved.

All of these use a Θ(n) fast-path when possible, which is sometimes O(1) in space and sometimes O(n).

Obtaining an array of all the above results is also optimsed. Obtaining an array of those iterators that can't special-case the operation themselves is also optimised as a side-effect of that.

[JonHanna]

There is also some work to make the worse-case less likely to be hit.

Which is a complexity not directly relevant and may not be worth it. I had been doing median-of-three, but I don't think that should be done here, so I took it out again. Whether it helps or hinders should probably be considered separately.

[JonHanna]

Or perhaps Empty() would be better. Since GetEnumerator() isn't hit in the original form, there's no meaningful observable difference this way, but there could be with Empty().

[JonHanna]

Rect: It does affect garbage collection. That effect is a generally good one (faster collection and perhaps in an earlier generation), but it is an effect that can be observed with finalisers or weak references, so it's not a completely unobservable change.

[dnfclas]

@JonHanna, Thanks for signing the contribution license agreement so quickly! Actual humans will now validate the agreement and then evaluate the PR.

Thanks, DNFBOT;

[JonHanna]

Test Innerloop Windows_NT Debug Build and Test

[EngrMHanif]

pulled