Thoughts from the EPS Windows Server Performance Team
Good morning AskPerf. Today’s post is a very short one, but it does address one of our most common Shell / Windows UI questions. That question is, “Why can’t I see the size of folders in Windows Explorer?” The simple answer is that the behavior is by design. You can view the size of folders by hovering over the folders in Windows Explorer (as shown below):
The primary reason why the Windows UI does not provide this functionality is performance. Every time you navigate through a folder structure in Windows Explorer, the OS would have to perform a recursive scan of the subfolder structure within each folder to get the file and folder sizes and add them up. This would create significant processor overhead – especially if you think about scenarios (home folders for example), where the nested directory structure for each user may be several levels deep and consist of thousands of files and folders. Extend the scenario from the local machine and add in users who are browsing through a directory structure across the network and the performance hit would grow exponentially.
The hover behavior above is governed by the “Display file size information in folder tips” setting on the View tab in Folder Options:
There are instances where turning this option off may provide a performance increase (for example, complex, multi-level nested folder structures) on the local system. When viewing complex folder structures across the LAN/WAN, client machines may experience significant delays. One other setting to be aware of is the NoRemoteRecursiveEvents registry setting (HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer). When this value is set to 1, Change Notify requests are turned off for file and folder changes occurring in mapped network share subfolders. If a file or folder is change in the root and first folder level of the mapped share, a Change Notify event is still sent by the server. However if a change is made at the second level (or deeper) in the structure, no Change Notify is sent. This registry setting is set on the client machines.
- Prabhakar Shettigar
We had this issue browsing a large structure over the WAN and had to change NoRemoteRecursiveEvents as noted above. At that time, the Microsoft engineer said that having SMB 2.0 capability on both ends would improve performance in this scenario (Vista/Windows Server 2008).
Perhaps in a future article, Microsoft could quantify the response time improvements (for a given, specific situation). I am still trying to understand if SMB 2.0 is hype or a significant improvement (15% or higher).
This is a decision that should be left to the user. By default, it is not there for performance reasons. Fine. But what about those users won't don't mind the slight performance hit on their uber geeky system? By removing IColumnProvider from Vista, you've crippled shell extensions which offered this feature. Extensions like folder size indeed cached the size in memory (the developer was planning to add size caching stored somewhere on disk as well) so there was no lag next time you visited the same folder hierarchy and then updated it without obstructing browsing or file management. I hope this changes by Windows 7 SP1. IColumnProvider was a very use way to enumerated information from multiple file system objects and removing it broke lots of utilities and column provider shell extensions. The new Property System requires developers to meddle with IPropertyStore, IStoreProvider and what not (Windows Search!) Besides, as a user, I prefer to stay on XP Professional for this simple but powerfully convenient functionality.