Improve inner-loop performance for .NET developers
DamianEdwards opened this issue · 16 comments
Summary
Inner-loop performance is critical to providing the developer experiences that are increasingly expected/demanded by developers. How fast developers can make code changes and see the resulting impact in their apps is directly proportional to how productive they can be.
When using other platforms, many of the common inner-loop operations are faster, sometimes dramatically so, than the equivalent when using .NET. First-time user impressions may be negatively impacted by such differences, to the point that it deters their choice of .NET as a developer platform.
Epics
Epics under this Theme:
- Improve performance of CLI/SDK/MSBuild that relate to the developer inner-loop.
- Improve and modernize the launch/debug/update loop
- Hot Reload application changes during development inner-loop from the .NET CLI
- Hot Reload for Blazor Components
- Hot Reload for ASP.NET Core
- Reimplement the Razor compiler using source generators & introduce incrementality
- Blazor WebAssembly Hot Restart
- Support Code Hot Reload (EnC) for Razor
- ASP.NET Core Hot Restart
- Xamarin developers have an improved development experience on .NET 6
- Ensure the BCL supports Hot Reload
- Reduce EF Core application startup time via compiled models
This is really very critical. From day to day i have pain with slow builds compared to Go compilation.
I notice this quite a bit when doing TDD, add one line of code, wait 30 seconds for it to compile and validate my test. I guess this would apply to the first two epics.
Updated the link for the Hot reload for Blazor components link.
will it add support jit reload on monovm?
Consider replacing the wwwroot/lib artifacts in new projects with content pulled from a package manager such as LibMan.
Maybe have the default content there, but have the config set up to link those resources to packages
is this expected to break IL weavers like postsharp and fody?
has a fast loop been considered for test execution? as in patching into a process that can run test?
I think development in C# should give good developer experience as in this talk: https://youtu.be/Yu9zcJJ4Uz0?t=416
In the end users will use languages which provide best development experience and other one will die.
And I think quick updating your code is critical in development like hot reloading of js in React / Angular...
I think in compilation should look like in https://www.snowpack.dev/ for js :)
Maybe using another compiler in development mode only and separate for release
In this case you can write test and lightining fast test it
The compilation should be incremental I think
@przemo098 I think Vite.js is the new gold standard that all other tools will be compared to in the foreseeable feature.
On a related note:
When running dotnet watch in terminal I often
- cannot see build errors/warning in VS error window
- cannot run tests, because VS runs it's own build and obj/*.dll files are locked by the
dotnet watch.
In other words, I either use dotnet watch and loose lot of VS tooling support, or I use run the app using VS (Debug or Run without debugging) and loose some of the live reload functionality.
Also, when debugger is attached and app is rebuilt, it could automatically reattach, resp. never detach. Just like when I set breakpoint in javascript file in Chrome's developer tools and refresh a page.
When can developers expect hot reload of Blazor (WASM) to be available? This is such a huge productivity enhancement that is crucial in successful adoption of Blazor.
super
Reduce EF Core application startup time via compiled models
Inner loop. smh. The terminology gets more embarrassing each... outer loop.
Great Efforts.
THIS IS GREAT. THANK YOU!!!
Closing this out as it pertains to work done in .NET 6.0