-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
- Convert SumF functions for Array, Span, and List into a generic function #20
base: master
Are you sure you want to change the base?
Conversation
Smurf-IV
commented
Jul 30, 2019
- Convert SumF function into a generic function
- Add new managed types (sbyte, byte, short, ushort, int, uint, long, ulong)
- Add tests for some of the new types
- Add new Benchmark tests
- Add new managed types (sbyte, byte, short, ushort, int, uint, long, ulong) - Add tests for some of the new types - Add new Benchmark tests
- Make sure publics have Intellisense - Add Nullable types - Perform template on source selectors
- Apply template to Spans<t> - Apply Template to List<T>
- Add List benchmarks
- Add SumF API's to redirect IList's to their base types
Hey Simon, wanted to say thanks for all the experiments you are doing here. I'll need to some time to review/test some of this stuff out, and I'm pretty busy with family/work all the time so it might take a while. I'll try to take a deep look in a few days and let you know what I think. |
No worries, Now that I have the templates in place, I can burn through the other types pretty quickly |
- Add inlining hint to AverageIList
I would hold off on doing too much work until I've had some time to review and test. I don't want you to write a million lines of code and then I end up not using them! |
- Fix code to make it appear "As fast" Via the use of the "Coming out faster" acum = accum nextVal method - Add ReadOnlySpan to `SumF` api's
- Done for Aggregate - Add All Span types - Add ReadOnlySpan - Reduce code in SumList
- Fix copy paste error - Add better intellisense text
…ower than just calling foreach -> Why?
…lower than just calling foreach -> Why?
…ReadOnlyList<T> - Change over to IReadOnlyList
…dOnlyList<T> - Implement LastF's the same way as FirstF's
…be implemented - Add Start File
…ReadOnlyList<T> - Use types instead of vars - Breakout Max Benchmarks - Breakout MaxF API's for different types into seperate files
…ReadOnlyList<T> - Split MinF's out into seperate files - Change to NameOf for Selector parameter
… on IReadOnlyList<T> - Replacement to use nameof for source - Split more benchmarks out into seperate relevant files
Just found a bog "No-no" in some of the "Optimisations" I've done
The big "No-No" is on the |
|
… in use - The IReadOnlyList<T> represents a list in which the _number_ and _order_ of list elements is read-only.
|
No on the |
…Benchmark - Add Ratio Comparisons to Benchmarks - Add .Net4.8 Output directories - Explicit call types for Average
… Benchmark - Attempt to sort why Appveyor is unhappy. - Sort out the ratio detection code when all are put back in.
No idea why AppVeyor is complaining, It runs on my machine !! |
…er a span Create jackmott#22: [Question] Span_FirstF and List_FirstF are slower than just calling foreach -> Why? Span this jackmott#24: [Enhancement] DefaultIfEmptyF should be implemented Add Span jackmott#25: [Enhancement] Please also target .net4.8 and Benchmark
…in the csproj file...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I see cursorily, it looks like there's a lot more changes than the title suggestions. Perhaps you could send a more focused/isolated review so that each of the changes can be evaluated on it's own merit (rather than one change having to block any benefit from the others due to being coupled)?
If my understanding of part of the change is correct about 'generic function' actually being 'use IReadOnlyList' then I'd be concerned about performance regressions when Array, Span, and List are passed in, as those have compiler/JIT optimizations for iteration.
@@ -245,12 143,12 @@ public static void SelectInPlaceF<T>(this List<T> source, Func<T, int, T> select | |||
{ | |||
if (source == null) | |||
{ | |||
throw Error.ArgumentNull("source"); | |||
throw Error.ArgumentNull(nameof(source)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isolating the changes would be a major help to reviewers. These, while potentially desirable, provide a lot of noise as they aren't "Convert SumF into a generic function"
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" /> | ||
</startup> | ||
<runtime> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoiding these kind of whitespace changes can help focus the review and speed up the review. In addition, it helps reviewers to stay focused so they can more likely catch issues
@@ -34,7 34,7 @@ public static T[] RepeatArrayF<T>(T element, int count) | |||
/// <returns>A sequence that contains a repeated value</returns> | |||
public static List<T> RepeatListF<T>(T element, int count) | |||
{ | |||
var result = new List<T>(count); | |||
List<T> result = new List<T>(count); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
more 'style' changes that aren't necessary
/// <param name="func">An accumulator function to be invoked on each element</param> | ||
/// <returns>The final accumulator value</returns> | ||
public static TSource AggregateF<TSource>(this TSource[] source, Func<TSource, TSource, TSource> func) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Converting T[] to IReadOnlyList makes it have to call through the interfaces for everything, which involves a vtable lookup. If this is a change (and not a reformatting artifact of moving things etc), then this would almost surely regress performance for arrays.