[campersau]

Problem

NDArrayHolderAnalyzer (NDW016/NDW017) can take minutes on projects whose types reference each other in cycles, even when those projects don't use NDArray at all. The analyzer ships in the NumSharp package, so it runs in every project that references NumSharp, directly or transitively.

Seen in a project that references NumSharp only transitively and doesn't use NDArray itself, but contains a larger domain model whose types reference each other in cycles. With -p:ReportAnalyzer=true:

	analyzer time	compile
NumSharp 0.70.0	321.6 s (NDArrayHolderAnalyzer, 99 % of all analyzers)	108 s
this PR	0.025 s	5 s

Both versions report the same diagnostics on that project (none).

Workaround until a release with this fix

ExcludeAssets="analyzers" on the package reference doesn't help: the SDK still passes the analyzer to csc, as build/NumSharp.targets notes. What works is removing it from @(Analyzer) before compiling, for example in a Directory.Build.targets:

<Project>
  <PropertyGroup>
    <!-- also skip the package's NDW013 fallback scan -->
    <NumSharpDisableWeaverMissingWarning>true</NumSharpDisableWeaverMissingWarning>
  </PropertyGroup>

  <Target Name="RemoveNumSharpAnalyzer" BeforeTargets="CoreCompile">
    <ItemGroup>
      <Analyzer Remove="@(Analyzer)" Condition="'%(Filename)' == 'NumSharp.Build.Analyzer'" />
    </ItemGroup>
  </Target>
</Project>

This turns off all NDW diagnostics, so it only suits projects that use neither the NDArray ownership rules nor [NDScoped].

Cause

OwnershipModel.HoldsCore memoized a "holds NDArrays" answer only when its walk had cut no cycle. HolderMembersOf also put the asking type itself on the walk. In a model whose types reference each other, nearly every answer involves a cycle, so almost nothing was memoized. Every type then re-walked every path through the graph, which grows exponentially with the size and density of the cycle. The holder analyzer does this for every named type of the compilation.

Fix

• HoldsCore runs Tarjan's strongly connected components over the "stores a value of" graph, so each type is visited once per walk.
• A true answer is memoized as soon as it is found. Finding one never depends on a cut cycle, so it is always exact.
• The types of one cycle (one strongly connected component) are memoized together, with the answer of the type the walk entered the component through. "Holds" is the least fixed point of an OR over the graph, so every type in a component holds exactly when its entry does.
• HolderMembersOf answers a source class/struct that holds no NDArrays straight from that memo instead of walking its members.
• For a type that does hold NDArrays, HolderMembersOf keeps the existing behaviour: the type stays on the walk's stack, so a member that reaches arrays only by coming back to the type itself adds nothing.

Tests

Two new tests in OwnershipRobustnessTests use a model of 14 types that all reference each other:

• DenselyCyclicModelWithoutArrays_CompletesClean: no diagnostics.
• DenselyCyclicModelWithAnArray_FlagsEveryType: one type stores an NDArray, and all 14 are flagged NDW016.

Both time out after 60 s on master and finish at once with this change. All 330 tests of NumSharp.Tests.Build.Analyzer pass on net8.0 and net10.0.

[Nucs]

Hey @campersau, appreciate your issue openning and fix.
I'll be merging your work and adding more fixes into a new minor release. Thanks!