Combine linq list optimisations by JonHanna · Pull Request #5777 · dotnet/corefx

JonHanna · 2016-01-29T14:52:51Z

A few different optimisations to Linq added recently can be usefully combined with each other.

Combine `IArrayProvider` and `IListProvider`

Anything that can be one can be the other, so merge the two interfaces into IIListProvider.

Anything implementing these can also fast-path Count(), so do so.

Have `IList<T>` optimised result of `Skip()` partitionable.

Optimisation of Skip() for IList<T> sources from #4551 fits with optimisations of Skip() and Take() for other sources from #2401.

Combine the approaches, extending how the result of Skip() on a list handles subsequent operations

stephentoub · 2016-01-29T17:15:55Z

cc: @VSadov

VSadov · 2016-01-29T20:38:57Z

LGTM nice change!

stephentoub · 2016-01-29T21:51:26Z

@JonHanna, I'm going to go through and review, but could rebase first to resolve the merge conflicts?

JonHanna · 2016-01-30T02:51:12Z

Nearly managed to have the simultaneous PRs out of each others way, but for one line.

stephentoub · 2016-01-30T04:04:02Z

Should SkipListIterator really be named SkipTakeListIterator?

Probably a better name. The current one shows its legacy more than its function.

stephentoub · 2016-01-30T04:45:38Z

Seems like there are some non-ASCII characters in the commit title:

c:\Users\stoub\Source\repos\corefx>git rebase master
First, rewinding head to replay your work on top of it...
Applying: Combine I?ArrayProvider and IListProvider

Warning: Your console font probably doesn't support Unicode. If you experience strange characters in the output, consider switching to a TrueType font such as Consolas!

stephentoub · 2016-01-30T04:46:13Z

Thanks for working on this. Seems like there are several non-trivial issues to address before this can be merged.

JonHanna · 2016-01-30T15:55:23Z

Hmm. A Left-To-Right Mark got into the title. I don't know what keypress makes that happen!

JonHanna · 2016-01-30T23:06:34Z

@stephentoub I've included the CountIsConstantTime property on IIListProvider, which allows code to decide whether it's Count can be used for an optimised collection-building path, but since nothing yet uses it, the drop in test coverage is due to that.

stephentoub · 2016-01-30T23:14:16Z

I've included the CountIsConstantTime property on IIListProvider

Thanks, though would it not make more sense to use a TryGetCount method like I suggested and avoid the additional interface call? Are there cases where you'd want to know it's cheap and not actually get it?

JonHanna · 2016-01-30T23:33:11Z

The problem with that approach is that there are two possibilities:

We want Count to facilitate an optimisation that is only worth it if Count is cheap.
We want Count. Obviously the cheaper the better.

All of the changes here improve the second case, which is the only case currently used.

The first would come up if we wanted to handle a subsequent operation on an IPartition with a class that would provide ToArray() or ToList(). I intend to do that for Select() (which already goes through a virtual call, so there wouldn't even be the cost of an extra type check), and no other method seems like a likely candidate.

Maybe what I should do is int GetCount(bool onlyIfCheap) and if true is passed and the operation wouldn't be sufficiently cheap, return -1.

JonHanna · 2016-01-31T00:09:26Z

I've done that. It does seem to give the best of both worlds.

JonHanna · 2016-01-31T16:46:02Z

Test Innerloop OSX Debug Build and Test
Test Innerloop OSX Release Build and Test
Test Innerloop Ubuntu Debug Build and Test
Test Innerloop Ubuntu Release Build and Test

VSadov · 2016-02-01T18:53:31Z

Does it look like this is always called with "false"?

Currently, yes. Through the comment trail, first I had this as a Count property and @stephentoub pointed out that someone might use it as a false economy in an optimisation that would be worse when that property wasn't cheap. I said that while it wasn't necessary yet, I'd plans for that (I'm holding back on further changes that build on this as the changes will be massive if I put them all in one PR) and brought a property that reported on whether Count was cheap or not. Stephen pointed out that this would mean two interface calls would be used, and agreeing with him I changed to this. As of right now though, it's still only called with false.

JonHanna · 2016-02-11T17:04:47Z

Test Innerloop CentOS7.1 Release Build and Test

JonHanna · 2016-02-11T17:44:14Z

Test Innerloop CentOS7.1 Release Build and Test
Test Innerloop OpenSUSE13.2 Debug Build and Test

JonHanna · 2016-02-11T18:56:07Z

Innerloop CentOS7.1 Release Build and Test
(Clean-up failure)

stephentoub · 2016-02-12T12:32:50Z

@dotnet-bot test this please

stephentoub · 2016-02-12T14:41:14Z

@dotnet-bot test this please

JonHanna · 2016-02-12T15:20:38Z

Test Innerloop CentOS7.1 Release Build and Test

stephentoub · 2016-02-12T16:37:04Z

            ICollection<TSource> collectionoft = source as ICollection<TSource>;
            if (collectionoft != null) return collectionoft.Count;
+            IIListProvider<TSource> listProv = source as IIListProvider<TSource>;
+            if (listProv != null) return listProv.GetCount(false);


Nit: would you mind using a named argument at the call site so that it's clear what the Boolean means? (Same for all the occurrences of this).

Sure. Of the three places this was called that weren't passing through that value, there was this and two cases where ListPartition called it on itself. I've made those two into a call to a private Count property, to make it clearer that the flag isn't relevant to that use.

That leaves this as the sole actual use of it, but I have plans for it 😄

stephentoub · 2016-02-12T16:48:21Z

+        {
+            IIListProvider<TElement> listProv = source as IIListProvider<TElement>;
+            if (listProv != null) return listProv.GetCount(onlyIfCheap);
+            return !onlyIfCheap || source is ICollection || source is ICollection<TElement>? source.Count() : -1;


Nit: space before the ?

I'll also swap the order of checking ICollection<TElement> and ICollection. If Count() takes that as the sensible order to check them, I should either do the same or else demonstrate why they should both be changed.

stephentoub · 2016-02-12T17:19:54Z

            if (partition != null) return partition.Take(count);
-            return TakeIterator(source, count);
+            IList<TSource> sourceList = source as IList<TSource>;
+            return sourceList != null ? new ListPartition<TSource>(sourceList, 0, count - 1) : TakeIterator(source, count);


Nit: FWIW, in cases like this where there's already a bunch of cases like:

IInterface1 i1 = source as IInterface1; if (i1 != null) return i1.Whatever(); IInterface1 i2 = source as IInterface2; if (i2 != null) return i2.Whatever(); ...

etc., I'd find the last one easier to understand as:

IInterfaceN iN = source as IInterfaceN; if (iN != null) return iN.Whatever(); return Whatever();

rather than:

IInterfaceN iN = source as IInterfaceN; return iN != null ? iN.Whatever() : Whatever();

Normally I like ?:, but in this case it breaks from the pattern used above it.

I agree. Skip() ended up with a ?: from the way its changes happened, and this was analogous and so ended up with it too, but I'll change both of them to the more consistent pattern.

Anything that can serve as one can serve as the other, and also provide a faster path for Count(). Merge the two interfaces and add a Count property. Have IList optimised result of Skip() partitionable. Optimisation of Skip() for IList sources from dotnet#4551 fits with optimisations of Skip() and Take() for other sources from dotnet#2401. Combine the approaches, extending how the result of Skip() on a list handles subsequent operations.

JonHanna · 2016-02-12T18:06:14Z

Test Innerloop Windows_NT Debug Build and Test please, because I'm not optimistic enough to ask about OpenSUSE.

stephentoub · 2016-02-12T20:11:35Z

LGTM

stephentoub · 2016-02-13T16:38:06Z

@VSadov, look good to you?

VSadov · 2016-02-15T22:18:57Z

LGTM

Combine linq list optimisations

…_optimisations Combine linq list optimisations Commit migrated from dotnet/corefx@6a0c20d

dnfclas added the cla-already-signed label Jan 29, 2016

JonHanna mentioned this pull request Jan 29, 2016

Remove unused paths in Set. #5778

Merged

JonHanna force-pushed the combine_linq_list_optimisations branch from 61722b4 to e981b71 Compare January 30, 2016 02:46

stephentoub reviewed Jan 30, 2016
View reviewed changes

JonHanna force-pushed the combine_linq_list_optimisations branch 3 times, most recently from dd9bc31 to b6b1e49 Compare January 30, 2016 22:49

JonHanna force-pushed the combine_linq_list_optimisations branch from b6b1e49 to 4e80453 Compare January 31, 2016 00:08

VSadov reviewed Feb 1, 2016
View reviewed changes

stephentoub reviewed Feb 12, 2016
View reviewed changes

JonHanna force-pushed the combine_linq_list_optimisations branch from 6871a86 to cd1d2b4 Compare February 12, 2016 16:46

stephentoub reviewed Feb 12, 2016
View reviewed changes

JonHanna force-pushed the combine_linq_list_optimisations branch 2 times, most recently from 6475a2b to 896553a Compare February 12, 2016 17:18

stephentoub reviewed Feb 12, 2016
View reviewed changes

JonHanna force-pushed the combine_linq_list_optimisations branch from 896553a to a087c2d Compare February 12, 2016 17:30

VSadov added a commit that referenced this pull request Feb 15, 2016

Merge pull request #5777 from JonHanna/combine_linq_list_optimisations

6a0c20d

Combine linq list optimisations

VSadov merged commit 6a0c20d into dotnet:master Feb 15, 2016

JonHanna deleted the combine_linq_list_optimisations branch February 15, 2016 22:41

stephentoub added the netfx-port-consider label Apr 13, 2016

svick mentioned this pull request Sep 18, 2016

Small perf tweaks for Select #11841

Merged

karelz modified the milestone: 1.0.0-rtm Dec 3, 2016

picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022

Merge pull request dotnet/corefx#5777 from JonHanna/combine_linq_list…

ac4899e

…_optimisations Combine linq list optimisations Commit migrated from dotnet/corefx@6a0c20d

Conversation

JonHanna commented Jan 29, 2016

Combine IArrayProvider and IListProvider

Have IList<T> optimised result of Skip() partitionable.

Uh oh!

stephentoub commented Jan 29, 2016

Uh oh!

VSadov commented Jan 29, 2016

Uh oh!

stephentoub commented Jan 29, 2016

Uh oh!

JonHanna commented Jan 30, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

stephentoub commented Jan 30, 2016

Uh oh!

stephentoub commented Jan 30, 2016

Uh oh!

JonHanna commented Jan 30, 2016

Uh oh!

JonHanna commented Jan 30, 2016

Uh oh!

stephentoub commented Jan 30, 2016

Uh oh!

JonHanna commented Jan 30, 2016

Uh oh!

JonHanna commented Jan 31, 2016

Uh oh!

JonHanna commented Jan 31, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JonHanna commented Feb 11, 2016

Uh oh!

JonHanna commented Feb 11, 2016

Uh oh!

JonHanna commented Feb 11, 2016

Uh oh!

stephentoub commented Feb 12, 2016

Uh oh!

stephentoub commented Feb 12, 2016

Uh oh!

JonHanna commented Feb 12, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JonHanna commented Feb 12, 2016

Uh oh!

stephentoub commented Feb 12, 2016

Uh oh!

stephentoub commented Feb 13, 2016

Uh oh!

VSadov commented Feb 15, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Combine `IArrayProvider` and `IListProvider`

Have `IList<T>` optimised result of `Skip()` partitionable.