TrimMode partial very slow to link

[markphillips100]

I've been using self-contained trimming to publish apps in linux docker images in .NET 6 for a little while now, and the link step usually takes about a minute or so. There are references to my own libs and 3rd parties that don't publish themselves as trimmable, so as expected, I get a ton of warnings, and of course the code isn't trimmed being that this is all .NET 6.

Moving along to .NET 7 RC.2 and when I use the default TrimMode "full" the app breaks as expected as all those warnings will be ignored and code removed. The link step is roughly the same length of time to complete though.

As documentation suggests, I switch to "partial" to obtain the previous .NET 6 behaviour. This time code is not stripped and the app works but the linker step takes 20 times longer. Literally 20 minutes to complete.

Anyone else experience this or know what might be going on? I don't have a repo I can supply for a reproducible example unfortunately, only my private code.

In the meantime I thought I might be able to use "full" trim mode if I resolve the warnings. Whilst I can set IsTrimmable false on my libs I don't know of a way of telling the linker to ignore a 3rd party lib that hasn't yet supplied an appropriate IsTrimmable. Is there some undocumented approach here?

[marek-safar]

/cc @sbomer

[vitek-karas]

@jtschuster for the perf question - I know that we fixed some perf issues recently, were the issues present in RC2? (and are we shipping the linker with them in 7.0 GA?)

[jtschuster]

@vitek-karas The worst of the regression was fixed here and should be included in RC1, but there was still a net regression and the fix has yet to be merged in. That fix slightly modifies behavior (though really just fixes buggy behavior), though, so I'm not sure if we could get it in GA.

[sbomer]

I don't know of a way of telling the linker to ignore a 3rd party lib that hasn't yet supplied an appropriate IsTrimmable. Is there some undocumented approach here?

You can set <IsTrimmable>false</IsTrimmable> on specific assemblies following this example https://learn.microsoft.com/en-us/dotnet/core/deploying/trimming/trimming-options?pivots=dotnet-6-0#trimming-settings-for-individual-assemblies.

[markphillips100]

@sbomer thanks for your suggestion. I completely missed that in the docs and will give it a try (in a few days hopefully) as if that at least gets me a working "full" trim mode build for .NET 7 when released then happy to incorporate trimmable deps as and when they support it.

[vitek-karas]

@jtschuster could you please try to see if we can repro the perf regression as mentioned by @markphillips100 ? If it's that severe I think we should at least consider doing something about it for 7.0.

[jtschuster]

Sure, I'll take a look. @markphillips100 if you're able to share some of the 3rd party libraries you're using, that could help me reproduce the issue.

[jtschuster]

Compiler generated code analysis could also be causing a slowdown. @markphillips100 do you use yield return, local functions, and anonymous functions a lot throughout your codebase?

@sbomer are there any other bottlenecks related to compiler generated code I'm missing?

[sbomer]

It's definitely possible that this could be related to compiler-generated code handling. The potential performance issues I'm aware of in that area are:

• Compiler-generated code is currently the only place we do a fixpoint-style analysis (iterating over the group of methods until the analysis converges). Certain patterns could make that analysis expensive by requiring many passes. This could in theory be an issue for non-compiler-generated code too, but we don't do a fixpoint analysis there currently.

• Compiler-generated code analysis makes a conservative approximation of values for hoisted locals, by tracking all values assigned in the group of methods. Certain patterns could result in large MultiValues with many tracked values. I think this can also happen in non-compiler-generated code, but the conservative analysis might make it more likely for compiler-generated code.

#2977 is one example of the latter issue, but it's probably easy to come up with others. We might need a general way to stop the analysis if it takes too many passes or tracks too many values, and emit a general warning like "this method was too complex to analyze".

I don't think #2979 is in 7.0 so it might be that issue, but it's hard to be sure - I think we need some kind of repro.

[sbomer]

if that at least gets me a working "full" trim mode build for .NET 7 when released then happy to incorporate trimmable deps as and when they support it.

@markphillips100 if you are looking to disable trimming for all assemblies that don't have the [assembly: AssemblyMetadata("IsTrimmable", "True") attribute, that is already the behavior of partial. The docs I linked are useful if you want to disable trimming case-by-case. Just wanted to clarify that in case it saves you some trouble.

[markphillips100]

@jtschuster I've used all 3 approaches in my libs that I reference, but not extensively. I can't speak for the 3rd party libs of course.

@sbomer Thanks for the heads up. I'm guessing that by applying this trim disabling during full mode I just makes the process approach partial's behaviour and so would encounter the same issue.

I think I'll try and come up with a repro if I can, at least see if I can isolate most of my code and perhaps pin down a smaller set of 3rd party libs just to make it easier on you all. Bit side-tracked on other work maybe the rest of this week so likely the weekend before I respond with what I come up with.

[jtschuster]

@markphillips100 One other thing that could help us narrow down the issue is if you try to use the latest linker build in your project. We just merged a couple of changes that improve performance, and if they fix the slowdown you're seeing, we could look into porting them back to .Net 7.

To do this, add a package reference to the latest linker build in your .csproj file:

  <ItemGroup>
    <PackageReference Include="Microsoft.Net.ILLink.Tasks" Version="7.0.100-1.22527.4" />
  </ItemGroup>

Then, add a nuget.config file if you don't already have one by running dotnet new nugetconfig in the same directory as the .csproj, and add the dotnet8 package sources by adding the <add key=...> line below.

<configuration>
  <packageSources>
    <add key="dotnet8" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/index.json" />
  </packageSources>
</configuration>

Hopefully trimming will be a bit faster.

[markphillips100]

@jtschuster that might be the quicker option to try. I'll hopefully get to it later today or at least over the weekend.