WinUI 3 Big impact on disk i/o perf

[Glockbert]

I have looked and not found this topic, if it's a repeat, apologies in advance.

New to WinUI 3. I am implementing a WinUI 3 front end to an existing C++ project. WinUI in C#, using standard DLL marshalling to make calls into my C++ engine. The engine deals with a lot of files (100k to 10m files) so a lot of work has gone into perf tuning with great results. All tests were run on latest Win11 release/updates, and fully updated SDK and Visual Studio 2022.

I was surprised to see about a 45% - 53% drop in perf when running under WinUI 3. I conducted a number of tests. I wrote a black box unit test that runs a scan of about 100k files. In the Win32 desktop C++ app this completes in about 4 minutes first run, about 1 minute second run, once the disk caches are loaded. For this discussion I will only talk about cached runs for simplicity other than to say speeds are impacted by same % cached or not). In WinUI 3, C# the same unit test time drops to about 1.5 minutes. This translates to many hours on larger data sets. (Note: HD is a 4 drive m.2 RAID over Thunderbolt 3, fast)

I went thru a process of elimination to see if I could root cause the issue. First I built a WinUI 3, C++ sample app ("click me") and launched the unit test. Got the same results. 1.5 minutes. So that eliminated C# as the problem (managed/unmanaged thread/memory transitions). Note: Test does not interact with the UI, so WinUI was "idle" during the test.

Next test was a C# .Net 8 Console app. Same interop layer to the C++ DLL. Ran the test. No perf hit. Test ran in 1 minute as it does under Win32. So again, C# isn't the issue, it seems to be the mere presence of WinUI effecting performance. This also seems to eliminate marshalling interop, as well as .Net 6/8, as causes. All that is left is WinUI itself. Puzzling.

Why is this titled disk i/o perf? I have another Unit Test that analysis a ton of the data that is collected. It does no disk I/O but operates on a large (fully in-memory) data set. I do not see ANY perf impact running this test under WinUI 3 in C# interop to C++ DLL, get the same results more-or-less, so it clearly points to something impacting read performance.

Finally, I did a final test to see if WinUI was somehow competing with Disk i/o or invalidating data caches. So I ran the WinUI 3 C# app concurrently with the Win32 C++ desktop app, and it did not impact performance on the Win32 app, so doesn't seem to be i/o contention or cache invalidation.

All of the perf discussions I could find center around UI frame rate of mostly UI related perf. Does anyone have any insight into this disk read perf issue? Why would (could) WinUI being degrading disk perf so badly in the same process? This is an unacceptable performance impact. My only option to keep the UI work at this point is to marshal to a separate process and run my engine as service, but that should NOT be needed just to use WinUI 3 for the interface. Any suggestions/feedback/ideas are welcome.

Thanks

[DarranRowe]

One thing I don't see any mention of is whether you are using WinUI 3 in a packaged application or unpackaged application.
By default, WinUI 3 uses the Windows APPX/MSIX packaging technology. This packaging technology includes filesystem virtualization and this may have an impact. Try switching your application to unpackaged to see if this helps. This is easy to do.

[Glockbert]

That's the information I was looking for. Still about 10% slower, but I suspect that's the threading model, will track that down. Not sure I'm happy that I can't be packaged and get acceptable performance. Thanks for your assistance. Is a 50% performance hit in this virtual FS documented anywhere? Is it a bug or just an unfortunate fact?

Edit: Now that I know what to look for, I have found it's documented as having a 50% hit on heavy file use scenarios. Also found some possible mitigations. Thanks again for clearing the mystery.