dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.95k stars 4.65k forks source link

Logging source generator reruns code generation phase on keypress. #93309

Open ericstj opened 11 months ago

ericstj commented 11 months ago

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:

  <Target Name="_disableLoggingGeneratorInDesignTime" BeforeTargets="ResolveOffByDefaultAnalyzers">
    <ItemGroup Condition="'$(DesignTimeBuild)' == 'true' OR '$(BuildingProject)' != 'true'">
      <OffByDefaultAnalyzer Include="Microsoft.Extensions.Logging.Generators.dll"
                            IsEnabled="$(EnableLoggingGenerator)"/>
    </ItemGroup>
  </Target>

Configuration

No response

Other information

No response

ghost commented 11 months ago

Tagging subscribers to this area: @dotnet/area-extensions-logging See info in area-owners.md if you want to be subscribed.

Issue Details
### 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: ```xml ``` ### Configuration _No response_ ### Other information _No response_
Author: ericstj
Assignees: -
Labels: `area-Extensions-Logging`
Milestone: -
ericstj commented 1 month ago

We discussed improving the incremental characteristics of the runtime source generators and scoped it out of 9.0

Youssef1313 commented 1 month ago

@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?