Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[Xamarin.Android.Build.Tasks] <FilterAssemblies/> in-memory cache (#4975
) In a customer's build log, a large solution build with no changes had: 1956 ms FilterAssemblies 18 calls The `<FilterAssemblies/>` MSBuild task runs on every build for class libraries and application projects. It looks at assemblies to classify them as a "MonoAndroid" assembly. Since we are already using System.Reflection.Metadata to open each assembly, we can use each assembly's MVID and `RegisterTaskObject` to skip future calls to the same assembly. This will be helpful in incremental builds in the IDE, as well as, large solutions that encounter the same assemblies throughout a build. Using the in-memory cache, we don't need to check any file timestamps. Unique MVIDs will yield the same result for the `<FilterAssemblies/>` task -- regardless if the assembly was built with `$(Deterministic)` or not. ~~ Results ~~ I did not have access to the original customer project, so I tested this change using xamarin/Xamarin.Forms@d9926450 instead. There are 8 Xamarin.Android projects during the build. Before: 165 ms FilterAssemblies 16 calls After: 156 ms FilterAssemblies 16 calls After (with MSBuild node running): 99 ms FilterAssemblies 16 calls Even on the first build, many assemblies are pulled from the cache. It printed ~326 instances of this log message: Task "FilterAssemblies" ... Cached: C:\src\Xamarin.Forms\Xamarin.Forms.Platform.Android.FormsViewGroup\bin\Release\FormsViewGroup.dll This saves ~10ms from an initial build of Xamarin.Forms' source and ~66ms from incremental builds. This will have a bigger impact on larger solutions. ~~ Other changes ~~ I removed an unused `DesignTimeBuild` property from `<FilterAssemblies/>`. I removed the log message: // In the rare case, [assembly: TargetFramework("MonoAndroid,Version=v9.0")] may not match Log.LogDebugMessage ($"{nameof (TargetFrameworkIdentifier)} did not match: {assemblyItem.ItemSpec}"); It is actually not a "rare" case, it was printed 330 times from the customer's log. This log message didn't add much value, so I removed it to reduce string allocations.
- Loading branch information