Open ericstj opened 11 months ago
Tagging subscribers to this area: @dotnet/area-extensions-logging See info in area-owners.md if you want to be subscribed.
Author: | ericstj |
---|---|
Assignees: | - |
Labels: | `area-Extensions-Logging` |
Milestone: | - |
We discussed improving the incremental characteristics of the runtime source generators and scoped it out of 9.0
@ericstj Note: Maybe for design-time builds, the generator could generate minimal code (partial method definitions without implementation), which could be fast and incremental, and fixes IntelliSense. And for actual builds the implementation is generated.
One potential consideration that I'm not sure about is, in what context does a build for EnC/HotReload happens? Is it a design-time build or non-design-time?
Description
See more detail in https://github.com/dotnet/runtime/issues/92914.
Reproduction Steps
Create a project that uses Logging source generator. Observe it's execution pattern - either in the debugger or through ETW.
Expected behavior
Changes unrelated to the logging code and it's type closure should not trigger regeneration of the logging source.
Actual behavior
Every change causes the entire pipeline to rerun.
Regression?
No
Known Workarounds
We haven't had reports of the performance here being a blocker, but that could be due to lack of use. The amount of work done on keypress will depend on whether or not the generator has work to do. If it has a lot of work to do, then it will be doing that work on every change. Disable the logging generator from design-time builds (this will result in errors where the generator is used, which are design time only errors). Workaround:
Configuration
No response
Other information
No response