3 ms·

I could be completely wrong, but my guess at the cause would be the registry. Every functionality and feature in Windows has a flag somewhere in the registry. E

I could be completely wrong, but my guess at the cause would be the registry. Every functionality and feature in Windows has a flag somewhere in the registry. Every query is probably a disk read, and it's a blocking operation of course. Sure, there's probably a cache, but that cache is only so large. There's a program that I can't recall the name of that can trace registry queries in the program it's attached to. You can attach to basically any process in Windows and see a monstrous number of registry queries.

londons_explore 5y ago
The registry is plenty small enough to keep the whole thing in RAM
emily-c 5y ago
A lot of critical system configuration is stored in the SYSTEM hive which isn't explicitly backed by a file mapping and is loaded at boot via firmware services so this will be fast as it is non-paged and mapped in kernel space for the entire boot session. On newer builds of Windows 10 other hives are memory mapped into the usermode address space of the minimal Registry process. Whenever you do a registry read the kernel will temporarily attach your thread to the Registry process' address space and the read to the UM mapped section will occur which will naturally fault in the data from disk. The requesting process' thread will then be unattached and the information will be returned. Since non-SYSTEM/ELAM hives are memory mapped the kernel's cache manager and memory manager subsystems are the ones that "own" and control the mapped memory. The file cache is tuned based on the particular system's hardware characteristics to be as performant as possible. There are registry-specific caches in between to reduce the need to attach to the Registry process but this isn't going to be a disk IO speed bottleneck. The program you're thinking of is procmon which is a part of the Sysinternals suite of tools.

londons_explore 5y ago

The registry is plenty small enough to keep the whole thing in RAM

emily-c 5y ago

A lot of critical system configuration is stored in the SYSTEM hive which isn't explicitly backed by a file mapping and is loaded at boot via firmware services so this will be fast as it is non-paged and mapped in kernel space for the entire boot session. On newer builds of Windows 10 other hives are memory mapped into the usermode address space of the minimal Registry process. Whenever you do a registry read the kernel will temporarily attach your thread to the Registry process' address space and the read to the UM mapped section will occur which will naturally fault in the data from disk. The requesting process' thread will then be unattached and the information will be returned. Since non-SYSTEM/ELAM hives are memory mapped the kernel's cache manager and memory manager subsystems are the ones that "own" and control the mapped memory. The file cache is tuned based on the particular system's hardware characteristics to be as performant as possible. There are registry-specific caches in between to reduce the need to attach to the Registry process but this isn't going to be a disk IO speed bottleneck. The program you're thinking of is procmon which is a part of the Sysinternals suite of tools.