Significant performance overhead in WinRT API calls (ApplicationData, Package.Current)

[ekalchev]

Describe the bug

I am seeing unexpected latency when calling standard WinRT APIs within a WPF application (Desktop Bridge/MSIX) using Windows App SDK 1.8.

Environment:
CPU: 12th Gen Intel i9
RAM: 64GB
Framework: Microsoft.WindowsAppRuntime 1.8

Observations:
Using both a profiler and Stopwatch verification, I’ve found that calls to ApplicationData.Current.LocalCacheFolder and ApplicationData.Current.GetPublisherCacheFolder consistently take ~25ms to execute.
Furthermore, these results do not appear to be cached internally; calling them multiple times results in the same 25ms delay per call. Other APIs show similar overhead:
Package.Current.InstalledLocation: ~15ms
ApiInformation.IsTypePresent: ~15ms
On high-end hardware, 15–25ms for a property access is extremely high. Is this expected behavior?

Steps to reproduce the bug

Just call any of those method and measure them with stopwatch

Expected behavior

No response

Screenshots

No response

NuGet package version

None

Packaging type

No response

Windows version

No response

IDE

No response

Additional context

No response

[DrusTheAxe]

Expected? Yes.

Could be better? Possibly (with work)

On high-end hardware, 15–25ms for a property access is extremely high

Because these properties are often doing more than just return this->string_attribute;.

ApplicationData.Current.LocalCacheFolder

That does 2 operations. Do you know the attributed cost?

ApplicationData.Current = query current process' package identity, query bookkeeping information and return an object

.LocalCacheFolder = query location information to get path for the local cache folder and create a StorageFolder

Performance can further vary depending if this is called in an AppContainer vs MediumIL+

One optimization in the backlog is to add .*Path properties equivalent to .*Folder but return the path as a string. The implementation's not quite as linear as one might think, so .*Path is expected to less cost to their equivalent .*Folder but it's hard to guess the delta. But regardless, if you need the path as a string and not a StorageFolder this should be a win.

these results do not appear to be cached internally
Correct - they're live calls, ByDesign. If you use them repeatedly you can cache their result.

Package.Current.InstalledLocation: ~15ms

Again, 2 operations -- Package.Current vs .InstalledLocation, and similar performance implications.

Package.Current (mostly) prepopulates the object with a snapshot of current information, and optimizations in the backlog to address this. See #6222 (comment) for more information.

.InstalledLocation likewise incurs the cost to create a StorageFolder object out of a path string, but .*Path properties are already available here e.g. .InstalledPath vs .InstalledLocation. As a general rule, if you don't need a StorageFolder object, always favor .*Path over *.Location.

ApiInformation.IsTypePresent

ApiInformation needs WinRT metadata thus it can involve a .winmd lookup and access to retrieve the type information. Depending on the type, caller's security context (AppContainer, MediumIL, etc) and other factors performance longer than instantaneous isn't surprising.

Better performance is always desirable, but are these problematic for you today?

[ekalchev]

Yes they are problematic. I am sorry that I want to build windows desktop application that have fast startup. When you have many winrt calls during startup they add up.

Are there alternative win32 calls of this winrt apis?

[DrusTheAxe]

Are there alternative win32 calls of this winrt apis?

There is no perfier alternative today to ApplicationData. WinAppSDK's Microsoft.Windows.Storage.ApplicationData today is powered by Windows.Storage.ApplicationData so it won't have any better performance. Something I hope to see improve in time, but not today.

If you don't need a StorageFolder Package.Current.InstalledLocation.Path is better done with Package.Current.InstalledPath, and often even better (more correct) with Package.Current.EffectivePath or GetPackagePathByFullName2. Depends if you're looking for your own path (so you know you couldn't have a Mutable or ExternaLocation path) or someone else's, and if you can call Win32 C exports vs need WinRT/projections.

ApiInformation has no alternative that I know of, other than the classic instantiate-the-object and trap ERROR_CLASSDB_NOT_REG, E_NOINTERFACE, etc as the not-found case. Ye' olde Beg-Forgiveness (vs Ask-Permission) sort of model.