Initialization of pages is very slow in 7.0.2

[curia-damiano]

Describe the bug

My customer is developing a big UWP application that uses the Windows Community Toolkit.
The behavior of the application is fine when using WCT 6.1.1.
After updating the NuGet package to 7.0.2, the application becomes very slow: it pretty unresponsive and in particular initialization of pages are very slow.

• Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:
  yes, it is a regression: it is ok in 6.1.1, it happens on 7.0.2

Steps to Reproduce

• Can this be reproduced in the Sample App?
  We are working in creating a POC.

Steps to reproduce the behavior:

1. Given the existing application, simply running it, it is very slow with the latest version of the NuGet package
2. With the visual studio profiler we have identified that the problem lays in GetXamlTypeByName

I attach here some screenshot showing the issue:

1. 
2. 
3. 
4. 

Expected behavior

We would expect the same performances we had in version 6.1.1.

Environment

NuGet Package(s):

Package Version(s):

Windows 10 Build Number:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [X] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (build number: )

App min and target version:
- [ ] Fall Creators Update (16299)
- [ ] April 2018 Update (17134)
- [X] October 2018 Update (17763)
- [ ] May 2019 Update (18362)
- [ ] May 2020 Update (19041)
- [ ] Insider Build (xxxxx)

Device form factor:
- [X] Desktop
- [ ] Xbox
- [ ] Surface Hub
- [ ] IoT

Visual Studio
- [ ] 2017 (version: )
- [X] 2019 (version: 16.10)
- [ ] 2019 Preview (version: )

Additional context

I attach here other text files about this issue:

1. threads1.txt
2. threads2.txt
3. threads3.txt
4. threads4.txt

Hello curia-damiano, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[Kyaa-dost]

@curia-damiano Thanks for highlighting this issue. Have you tried it in a different machine? or reinstalling it to see if you are seeing similar response time?

[michael-hawker]

@curia-damiano can you provide some more details here please:

• What controls are you using from the Toolkit on the pages you're navigating between?
• Is this only during Debug more or with the Debugger attached?
• Can you reproduce this in an isolated project?
• Have you tried the 7.0.0 or 7.0.1 packages to compare?

The Controls package is a meta package in 7.0 now as well. If you're only using a few things from the Controls side, you should scope down to include in individual packages that you need within it, i.e. if you're not using the MarkdownTextBlock don't include that package.

We haven't seen any issues while developing and deploying our Sample App which includes all the controls, so there's some other piece of info that's added to your scenario that is missing for us to investigate any further.

[curia-damiano]

Hi @Kyaa-dost and @michael-hawker,
sorry for my delay in answering to the request of information for this issue.

During these months we have updated to 7.1 and lately to 7.1.2, but we still have the same issue.
In all versions, the issue still happens.

So:

• compiled in Debug mode, the application runs normally, without any slowness, but from the debugger and out from it;
• when compiled in Release mode, it's really noticeable that opening each form for the first time takes a lot of time (inside its InitializeComponents method);
• after the form has been loaded for the first time, then it will open normally (inside the same run execution, i.e. without restarting the application);
• if we restart the application, again opening a new form for the first time takes a lot of time.

I have this happening on my local machine, but if needed, I can setup a VM in Azure to reproduce the issue.

You can reach out to me also via d a m i a n o dot c u r i a at m i c r o s o f t dot c o m

[curia-damiano]

Here is a trace collected with dotTrace:

You see that the majority of the time is spent in some RHBinder function, that is not user code.

Also from this:

we see that 99% is spent on native code, but also that 99% is spent waiting (strange imo).

[michael-hawker]

Hi @curia-damiano, between 6.1 and 7.0 we made the Controls package a meta-package to include all our controls, as we created smaller sub-packages to reduce application foot-print size. I'd be curious if the same issue exists if including only the required packages directly vs. the entire controls package.

I can reach out to you directly for more info, if that's more effecient.

[curia-damiano]

Hi @michael-hawker, as suggested by you, I have replaced the inclusion of the full Microsoft.Toolkit.Uwp.UI.Controls with the more specific NuGet packages.
This has solved the slowness of my customer.