Regression in startup time 0.9 -> 0.10.

Describe the bug

One of our customers has made us aware of a regression in startup time between 0.9 and 0.10. Tested this on my machine and found that this is indeed the case.

I measured the startup time in a blank app by starting a System.Diagnostics.Stopwatch in Program.Main and stopping it in the main window Activated event. The program was compiled in a standard release build and with a ReadyToRun (R2R) deployment:

Version	Theme	Startup	R2R
0.9.12	Default	0.36s
0.10.0	Default	0.71s
0.10.0	Default	0.45s	x
0.10.0	Fluent	0.85s
0.10.0	Fluent	0.49s	x

Wasn’t able to test 0.9 in R2R mode as the program fails to run.

I will report the results of my investigation below.

[grokys]

Yes, #8263 and #8422 should help with this when they’re finished, though we don’t have any numbers yet.

[grokys]

My next port of call was to try to work out just why the Fluent theme is so much slower. It’s a much bigger more complex theme than Default of course so there would be some performance cost to be expected; however I wanted to see if I could improve startup time with this theme as this is what most people would be using.

My initial profiling led me to see that we’re calling StyleInclude.TryGetResource nearly 50,000 times on startup and that we’re doing more than 80,000 resource lookups. When the SystemAccentColor is read for the first time, these are the resulting ~8000 calls to StyleInclude.TryGetResource:

https://gist.github.com/grokys/5d1a3ded2509808807b5e699f5876672

That doesn’t look good. What’s happening is that the first call to get a resource causes the fluent theme to get loaded which triggers all the resources in those styles to be looked up, and for each resource lookup all the XAML files in the fluent theme need to be searched. The process of loading the fluent theme takes around 0.5s in total.