MSBuild - Xaml MarkupCompile passes slow

[asears]

Describe the bug

References: dotnet/wpf#3954

When running msbuild against a uwp project, the steps to compile XAML are very slow performing in relation to other tasks.
Are there any improvements or caching that can be done to speed up compilation times related to XAML?

Running Windows 10.0.17763.0 XamlCompiler.

C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\XamlCompiler\Microsoft.Windows.UI.Xaml.Common.targets

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'

Expected behavior

msbuild -maxCpuCount:4 -v:m -bl -clp:PerformanceSummary;ShowCommandLine;ShowTimestamp

Screenshots

Sample of relevant csproj properties

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="15.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
    <PropertyGroup>
   <RuntimeIdentifier>win10</RuntimeIdentifier>
  <TargetPlatformIdentifier>UAP</TargetPlatformIdentifier>
  <TargetPlatformMinVersion>10.0.17763.0</TargetPlatformMinVersion>
  <AppxBundlePlatforms>x86|x64</AppxBundlePlatforms>

Version Info

NuGet package version:

 <PackageReference Include="Microsoft.NETCore.UniversalWindowsPlatform">
      <Version>6.2.9</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Toolkit.Uwp.UI.Controls">
      <Version>5.1.1</Version>
    </PackageReference>
    <PackageReference Include="Microsoft.Toolkit.Uwp.UI.Controls.DataGrid">
      <Version>5.1.0</Version>
    </PackageReference>
    <PackageReference Include="Redux.NET">
      <Version>2.0.0</Version>
    </PackageReference>
    <PackageReference Include="Telerik.UI.for.UniversalWindowsPlatform">
      <Version>1.0.1.7</Version>
    </PackageReference>
    ```

<!-- If you are using WinUI 3, please specify for which Windows app type you have encountered the issue. Leave blank if you didn't try that app type. -->
Windows app type:
| UWP              | Win32            |
| :--------------- | :--------------- |
| <!-- Yes/No? --> | <!-- Yes/No? --> |

<!-- Which Windows versions did you see the issue on? Leave blank if you didn't try that version. -->
| Windows 10 version                  | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx)              | <!-- Yes/No? -->   |
| May 2020 Update (19041)            | <!-- Yes/No? -->   |
| November 2019 Update (18363)       | <!-- Yes/No? -->   |
| May 2019 Update (18362)            | <!-- Yes/No? -->   |
| October 2018 Update (17763)        | Yes   |
| April 2018 Update (17134)          | <!-- Yes/No? -->   |
| Fall Creators Update (16299)       | <!-- Yes/No? -->   |
| Creators Update (15063)            | <!-- Yes/No? -->   |

<!-- Which device form factors did you see the issue on? Leave blank if you didn't try that device. -->
| Device form factor | Saw the problem? |
| :----------------- | :--------------- |
| Desktop            | Yes/No |
| Xbox               | <!-- Yes/No? --> |
| Surface Hub        | <!-- Yes/No? --> |
| IoT                | <!-- Yes/No? --> |


**Additional context**
<!-- Enter any other applicable info here -->

Here is an example of the steps being run.

```plaintext
  10303 ms  MarkupCompilePass2                         2 calls
    14030 ms  MarkupCompilePass1                         2 calls

Analysis

Versions & Configurations

msbuild 16.8.2.56705

Triggering build perf test from command line. Visual Studio 2019 Enterprise is slower.

[StephenLPeters]

@alwu-msft or @RealTommyKlein fyi

[stevenbrix]

Thanks for filing this issue @asears.

We have #1535 open related to compiler perf, unless you think there is a reason to have separate issues, I'll close this as a dupe

[asears]

Sure thing, close it as a duplicate unless you can use this issue to target / track optimizing the 2 Xaml compile tasks and targets. Might be simpler. The issue you linked seems to relate to upgrading to fix the performance regression issues. A drop-in replacement to these xaml tasks & targets or some pointers on addressing the build issues with msbuild flags would be much appreciated instead of code updates or upgrades. Shouldn't need to change code to fix build tooling performance?

The build doesn't seem to take into account the fact that the xaml/cs files haven't changed, and looking internally at the .NET Framework code for those 2 compile tasks seem to have much room for perf tweaks.

There are two other issues we're having which may be associated to these tasks:

• the incorrect detection of language by filename (which is picking up some unit tests and throwing a compiler warning)
• the inability to overwrite files during the build (which could be caused by switching appdomains, threads or target permissions in the compile task).

I see this option. How do we pass it in to msbuild/will it help? How do we avoid the 2nd pass compilation?

AlwaysCompileMarkupFilesInSeparateDomain | Optional Boolean parameter.Specifies whether to run the task in a separate AppDomain. If this parameter returns false, the task runs in the same AppDomain as MSBuild and it runs faster. If the parameter returns true, the task runs in a second AppDomain that is isolated from MSBuild and runs slower.

Would be nice if a fix for performance regression could be backported for the community. Appreciate any help.

[RealTommyKlein]

@asears - unfortunately, there isn't much in the way of MSBuild flags to address the performance issue. The current slowness in the Windows.UI.Xaml compiler is due to its core logic of evaluating which .xaml files it needs to reparse. As far as MSBuild flags, it looks like you're looking at the documentation for the WPF compiler. The Windows.UI.Xaml compiler doesn't have that AlwaysCompileMarkupFilesInSeparateDomain parameter, and for Windows.UI.Xaml the 2nd compilation pass is MarkupCompilePass2 is always required.

[JeanRoca]

Closing as dupe and known issue.