Re:Performance Improvements in .NET 7
by jeremycarter on Wednesday August 31, 2022 @04:14PM
(#32667748)
Thanks for your hard work with the .NET community David.
Re:Performance Improvements in .NET 7
by davidfowl on Wednesday August 31, 2022 @11:52PM
(#32671735)
Thanks for using .NET!
Actually system text json does work with source generators and di can work with source Generators aswell.
Re:Performance Improvements in .NET 7
by davidfowl on Wednesday August 31, 2022 @12:34PM
(#32664674)
Thanks for telling me :). On a serious note though, anything can work with source generators but it doesn't match the style of coding that we'd like (moving everything to be declarative isn't the path we want to go down for certain APIs). Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator (if we wanted to keep things NativeAOT safe). Right now most of the APIs you use in ASP.NET Core are imperative and source generators cannot change the callsite so you need to resort to method declarations and attributes everywhere.
That's not an optimization, that's a programming model change.
> Also source generators don't compose, so any source generation that we would want to use would need to take advantage of the JSON source generator
This is the biggest challenge I see, there are times where either Expression.Compile or T4 still 'feels' cleaner than sourcegen.
Well in system text json the api keeps the same and you „only“ need to pass an autogenerated meta object its basically the same api you just need to pass another object instead of an generic Parameter. But yeah its a change.
- https://github.com/davidfowl/FasterActions - https://github.com/davidfowl/uController
They are source generated version of what ASP.NET does today (in both MVC and minimal APIs). There are some ergonomic challenges with source generators that we'll likely be working through over the coming years so don't expect magic. Also its highly unlikely that ASP.NET Core will not depend on any form of reflection. Luckily, "statically described" reflection generally works fine with NativeAOT.
Things like configuration binding, DI, Logging, MVC, JSON serialization all rely on some form of reflection today and it will be non-trivial to remove all of it but we can get pretty far with NativeAOT if we accept some of the constraints.
As of right now, we're trying to make sure "motivated people" can play with it, but it's not something that is supported by ASP.NET Core or EF at the moment. https://github.com/dotnet/aspnetcore/pulls?q=is%3Apr+nativea...
PS: Some of the challenges https://github.com/dotnet/aspnetcore/issues/42221