←back to thread

201 points olvy0 | 1 comments | | HN request time: 0s | source
Show context
louthy ◴[] No.41880271[source]
"LINQ Performance improvements" really should read: "our own List<T> implementation performance improvements". Microsoft seem to spend their time improving what they need, rather than spending time on general improvements. LINQ (the syntax, not the method extensions) needs investment. Primarily around lambda allocation and potentially on compile-time reduction of lambdas.

It's time to have value-type local lambdas, or a strategy that doesn't make lambda allocation the overhead that it is. And also there really should be wildcard support (`_`) for LINQ variables by now. Which was been completely ignored when they were brought in for lambdas. It should also be possible to use a lifted-type (like IEnumerable<T>, Option<T>, etc.) as the final item in a LINQ expression, rather than `select ...`. The select adds overhead that isn't needed for certain use-cases and limits things like tail-recursive LINQ expressions.

Libraries like mine that go all-in on LINQ [1], but aren't using `IEnumerable` or `IQueryable`, or any of the LINQ extensions, continually get ignored because MS are focusing purely on improving the performance of their own projects.

A good example is the improved lambda inference. It was only brought forward because ASP.NET Core needed it for its minimal API. It seems like many of the features of the language/framework are driven by their own needs rather than those of the community. The absolute worst thing is the ever expanding set of 'magic methods' (like the LINQ extensions Select, SelectMany, and Where, but also GetAwaiter, and the rest). MS are adding capabilities for themselves (the compiler mostly) rather than do what is really needed and add proper higher-kinded traits to resolve the magic. So everything is weakly typed and only vaguely discoverable by the compiler :/

LINQ is one of those key differentiators between languages, yet it's been wallowing, pretty much untouched since C# 3. I think it's a crying shame that it has basically been ignored since then and, even now, they think LINQ is only useful for iterating lists. And primarily only their own list implementations.

/rant

Don't get me wrong, I appreciate all performance improvements, I'm sure it will help plenty of users. But the focus always seems to be narrowly targeted, which limits the potential.

[1] https://github.com/louthy/language-ext/

replies(2): >>41883339 #>>41884775 #
neonsunset ◴[] No.41883339[source]
If you do have useful feedback, please submit an issue or contribute a PR to dotnet/runtime. That’s how many performance improvements in LINQ come to be, that the post discusses.
replies(2): >>41883537 #>>41888060 #
louthy ◴[] No.41883537[source]
7 years ago: https://github.com/dotnet/csharplang/issues/1060

3 years ago: https://github.com/dotnet/csharplang/blob/main/meetings/2021...

I've given up submitting to csharplang now. It seemed like a positive when it was first open-sourced, but the proposals/issues are often just circular discussions that go nowhere. It doesn't feel like (at least from the outside) any proposal by a non-MS employee would make it thru the process unless MS needed it themselves. Which is what I was alluding to in my original post.

I may well be wrong and maybe some proposals have made it through, but it feels like an illusion of community collaboration rather than actual community collaboration imho. I don't expect preferential treatment or anything like that, but it would be good if one of the most standout features of C# got some proper attention after a decade of neglect.

There has been a lot of effort on performance in many areas of the framework and the language. Leveraging that work for LINQ (the language feature) would be very welcome.

replies(1): >>41884173 #
neonsunset ◴[] No.41884173[source]
C# is already big enough language. This is more about .NET in general and less about C# specifically.

From what I've heard - there is an awareness that the current cost of delegates, while not that problematic anymore, can be improved. Whether this happens via explicit syntax to enable (ref) struct closures and value delegate pattern implementations or via object escape analysis and better devirtualization remains to be seen.

p.s.: I really wish that instead of LanguageExt, companies would have adopted F# instead.

replies(1): >>41884217 #
louthy ◴[] No.41884217[source]
> p.s.: I really wish that instead of LanguageExt, companies would have adopted F# instead.

Ah the standard "why don't you just use F#" line. I have a standard response to that now ;)

https://github.com/louthy/language-ext/wiki/%22Why-don't-you...

replies(1): >>41892502 #
1. neonsunset ◴[] No.41892502[source]
Thanks, I did read the reply before but remain skeptical. The reason for this is "strictly-managed" teams are also often resistant to libraries in a similar way. Fully adopting a high-end solution like LanguageExt can be seen as significant commitment. If a business case justifies that, it means that adopting F# could be on the table too. And unlike Haskell, integrating "functional core" into existing .NET solutions is very easy and has low amount of friction, much less so than people tend to assume upon hearing the suggestion.