[Perf] Improve launch perf about devhome HOT 15 CLOSED

@asklar The pipeline run completed successfully and the latest 1.4 Nuget package can be found in the drop_Aggregate_BuildWindowsAppSDKPackages folder of the published artifacts. Please test and profile this build against DevHome ASAP (this is the prior build to serve as the baseline). Shiproom wanted to give the change more bake time so the fix has been approved for 1.3.2, but if your testing on typical hardware (i.e. not an AMD Ryzen 9 7950X with 64 GB of RAM and a PCIe 4.0 NVMe SSD) indicates a significant and user-visible improvement in performance then they are willing to pull it forward into 1.3.1.

from devhome.

I can bring it up in shiproom today although I don't think it will be immediately approved. It looks like this will be the first build of WinAppSDK that contains my fix: https://dev.azure.com/microsoft/ProjectReunion/_build/results?buildId=69350636&view=results. Assuming it completes successfully, can you smoke test it in DevHome ASAP? I suspect we'll need that information in order to make our case for a backport.

from devhome.

Oh, I should also mention (in the interests of full disclosure) that in my own testing DevHome's wall clock time did not meaningfully change despite the reduction in CPU usage; my best guess is something else is the true bottleneck. But I also have very high-end hardware so YMMV.

from devhome.

@asklar @evelynwu-msft We have to ship with the 1.3.1 servicing release (expected May 9 release) because we need the widget service updates from that version.

from devhome.

@asklar Yes, I will be looking at it.

from devhome.

In my analysis, I am seeing a 1% improvement in wall clock time and 3 MB memory improvement. I also did an experiment where I reverted back to the commit from before we merged all our setup flow projects together and with that I am seeing a 94% improvement in wall clock time. So the change does indeed improve things, but I think we will be fine waiting for 1.3.2 due to our current merging of the projects.

from devhome.

thanks Mano! 1% is probably ok to wait for :)
And thanks Evelyn, 94% in the naïve design would have been immense :-D Other customers that use many libraries/components are sure to be happy!

from devhome.

Thanks for getting us those numbers @manodasanW!

from devhome.

Is the perf after #148 acceptable or do we need to still improve it more?

from devhome.

@asklar The linked WinUI bug has been fixed internally (https://microsoft.visualstudio.com/DefaultCollection/WinUI/_git/microsoft-ui-xaml-lift/pullrequest/8798865) although Flor's change already captured the vast majority of the potential perf improvements. Having said that, does it add enough perf improvement on top of her change that we should try to backport it in time for use by DevHome?

from devhome.

thanks for the heads up and for the fix @evelynwu-msft!
6% is pretty huge, and 2MB less sound like it's worth considering, so my vote would be for backporting to whichever version we'll ship with. @EricJohnson327 or @ujjwalchadha can confirm which version it will be (might be ok for this to be in 1.3.1?)
Who do we need to bribe? :)

from devhome.

good to know, thanks a lot Evelyn!

from devhome.

awesome! @manodasanW are you able to test this out and see what gains we get?

from devhome.

@manodasanW @asklar can I close this issue? Looks like we're now using 1.3.2

<PackageReference Include="Microsoft.WindowsAppSDK" Version="1.3.230331000" />

from devhome.

Closing. Please re-activate if necessary.

from devhome.