Huge performance drop when using `--collect:"XPlat Code Coverage"` in `dotnet test` (.NET 6)

I have an NUnit test project with a dependency on coverlet.collector v3.0.3 which becomes unusable when dotnet test is invoked with --collect:"XPlat Code Coverage".

Repro steps:

git clone https://github.com/lynx-chess/Lynx
git checkout 8dd27e9cb2863c6e538638b4482154270ca00525

dotnet test .\tests\Lynx.NUnit.Test\ -c Release --filter "Mate_in_2" # 1s
dotnet test .\tests\Lynx.NUnit.Test\ -c Release --filter "Mate_in_2" --collect:"XPlat Code Coverage" # 47s

dotnet test .\tests\Lynx.NUnit.Test\ -c Release --filter "TestCategory=LongRunning"  # < 4 min
dotnet test .\tests\Lynx.NUnit.Test\ -c Release --filter "TestCategory=LongRunning" --collect:"XPlat Code Coverage"  # Never ending

See also some GH Actions runs (see long-running tests -> Run long-running tests):

• Run 1: With coverlet.collector and with --collect:"XPlat Code Coverage" - Manually cancelled after 45 min 🔴
• Run 2: With coverlet.collector and without --collect:"XPlat Code Coverage" - ~2.5 min ✔️
• Run 3: Without coverlet.collector and without --collect:"XPlat Code Coverage" - ~2.5 min ✔️(the failure in the next step of the job is unrelated)

---

Versions;

6.0.100-preview.5.21302.13

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="NUnit" Version="3.13.2" />
    <PackageReference Include="NUnit3TestAdapter" Version="4.0.0" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.10.0" />
    <PackageReference Include="coverlet.collector" Version="3.0.3">
      <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
      <PrivateAssets>all</PrivateAssets>
    </PackageReference>
  </ItemGroup>

[winterlimelight]

(edit) I withdraw my original comment. I had a misconfiguration which meant the Migrations were being included in the coverage. Once the appropriate exclude filters were actually applying then run time has dropped to normal levels. (https://github.com/coverlet-coverage/coverlet/blob/master/Documentation/VSTestIntegration.md)

[MarcoRossignoli]

To be sure that issue is what I expect someone should take a dump of process and check if threads are for most of the time inside RecordHit or RecordSingleHit

In that case for now we don’t have a solution 😞

Coverlet instrumentation relies heavily on sequence points and not “blocks” so for every sequence point it emits a “hit records” that despite inlined(is a update indexed array location with +1) can lead to perf issue or maybe to some missing optimization due to “more code to run”. I have one idea of replacing completely the sequence points engine with a “block engine” but it’s very huge work.