Net 9.0 LINQ Performance Improvements

It's just an API for JIT, basically metaprogramming. It's cool but you can definitely do a similar thing in pretty much every high level language.

With scripting languages, it's all JIT :)

The C# teams progress on this has been slow. Keep in mind the CIL bytecode has had such capabilities for at least 20 years now and only in the past like decade are we seeing more features and optimizations around LINQ and System.Reflection.Emit.

Dynamics were extremely slow in C# and if you look at the CIL generated you see why. It's possible for example to use something like a Haxe anonymous types[1] to optimize Dynamics so that CallSite caching is way more performant.

I am pretty sure in C# the only way to accept an anonymous type is as a dynamic value, so even though the type of the structure is well-defined at compile-time, it will still rely heavily on runtime reflection/DLR with no additional caching beyond what DLR does for any other dynamic type.

Anyways, this leads to niche libraries being built for handling dynamic data like JSON performantly.

Which leads to annoying things like .NET libraries/apps being incompatible (without some adapter) if they use for example, different JSON libraries under the hood. (See [2]).

Problems like these (the lack of actually good JIT/dynamic code support) in my opinion significantly slow down the .NET ecosystems development, that's why it always feels like .NET is just catching up with features other popular languages have.

To be fair though, much of C#'s lag is owed to Microsoft's contribution to .NET being mostly technical debt. Almost everything good that came out of .NET came from open source/non MS teams (like Mono).

[1] - https://haxe.org/manual/types-anonymous-structure.html

[2] - https://learn.microsoft.com/en-us/dotnet/standard/serializat...

> It's cool but you can definitely do a similar thing in pretty much every high level language.

No. When it was release (circa 2007), very few mainstream languages embraced "Code as Data" the way C# did. In Java, there was no way to pass an expression (as an AST) to an SQL library. Which is why LINQ is so much more ergonomic than Hibernate. In C#, you could use language features you're already familiar with (such as "order.id > 100 && order.id < 200") in your queries, whereas Hibernate made you learn the framework's specific patterns (add Criteria etc etc, I don't recall now). Java just wasn't expressive enough for this.

In fact, you couldn't do this even today in a language like say Python or JS. I mean, not without running it through something like babel to get an AST, and having arbitrary rules on what's code and what's data. C# had this in the spec; based on whether it was IQueryable.

> Almost everything good that came out of .NET came from open source/non MS teams (like Mono).

My team adopted Mono very early - like in 2005. Your statement is not true at all. C# and the Framework was a very good spec irrespective of what Open Source / Mono did, and while Mono existing might have accelerated .Net's transition into Open Source, it would have happened anyway due to the definitive swing towards Open Source in the 2000s. Linq-to-SQL, Asp.Net MVC, EF etc didn't come out of Mono.

C# generics will handle anonymous types just fine. That's what lets you write stuff like `from ... select new { ... } where ...`.

Have you ever read the source code for Microsoft's ilasm compared to Mono ilasm?

Anyway, EF is cool, but probably every .NET dev has an EF/LINQ performance related horror story (the generated queries are ridiculous).

A self compiling language is more impressive to me than ASP.NET MVC.

And C# is just lacking for what is actually capable in CIL bytecode. Or _was_ when I last used.

There have definitely been improvements, but in my opinion, they have just been kind of slow.

When I think of Microsoft's impact on .NET and it's culture, I think of stuff like SOAP, the SmtpClient, breaking changes in APIs every year and the technical debt left by it, the dogmatic fanboys, etc...

ilasm is for manually writing IL-based programs in text format, a rather rare use-case. How is this related to LINQ?

It's related to MS contribution to .NET which is the subtopic of this particular thread.

I don't see how it is related is relevant to this discussion. Is there a specific point you would like to make?

> probably every .NET dev has an EF/LINQ performance related horror story (the generated queries are ridiculous)

> There have definitely been improvements, but in my opinion, they have just been kind of slow.

> much of C#'s lag is owed to Microsoft's contribution to .NET being mostly technical debt. Almost everything good that came out of .NET came from open source/non MS teams (like Mono).

Do you actively use .NET (any modern target in the last, say, 3-4 years or so)?