I think the issue is actually the sandboxing and other stuff. WinRT StorageProvider API is known to be extremely slow and NTFS / Windows IO subsystem is itself

I think the issue is actually the sandboxing and other stuff. WinRT StorageProvider API is known to be extremely slow and NTFS / Windows IO subsystem is itself already quite slow compared to UNIX. The issue IIRC is that StorageProvider is designed for sandboxing and the way they implemented that involves doing RPCs to other processes. So there's probably some heavy context switching involved, but it's architectural, and so the voice recorder was never fixed. https://github.com/microsoft/WindowsAppSDK/issues/8 https://github.com/microsoft/WindowsAppSDK/issues/8 "The challenge here is simply that listing the StorageItems in a StorageFolder is incredibly slow and resource intensive compared to using the standard .Net/Win32 API to list the file paths. A quick test showed that in .Net it takes about 0.003ms per file, whereas with UWP StorageItems it takes about 2ms per file, which is around 700 times slower. Also, looking at the Runtime Broker, UWP uses about 70kB memory per file, which is a huge cost when loading 10,000+ files, whereas .Net uses around 0.1kB per file (that’s a very rough estimate)." Somewhere else, someone proposes a theory that due to API mismatches/design issues in Win32 the RuntimeBroker is trying to use a design that isn't a great fit in order to try and provide certain security guarantees, and this requires pre-fetching a lot of data up front in case the app requests it. But NTFS is slow, so, all this additional traffic makes opening files via the Storage API really really slow. The problem here isn't really "modern software", it's that Microsoft wrote a lot of new APIs over time with the intention of replacing Win32 (UWP/WinRT) but they aren't dogfooding them all that effectively, and they're using C++ for everything, so there are problems that don't get fixed for years.