Faster Dir Size calculations in Powershell!

Get-ChildItem is probably the command that's most used when working in PowerShell console. Next to file-system operations the command is also excellent to browse objects accessible via PSDrive(s).

Most sysadmin's are probably familiar with tools such as TreeSize and/or WinDirStat. Did you ever wonder why these tools are so much faster than Get-ChildItem? There is even a PowerShell TreeSize implementation available on the PSGallery, however it's pretty slow when running on large file-servers.

The downside of Get-ChildItem is that it will not let you grab a sub-set of properties. It seems likely that this is one of the reasons GCI is slow.

The following 3 commands will all produce the same result, which is the total Dir Size in bytes:

Dir size explorer

Dir size in Windows Explorer

All commands come close enough with only a 1MB deviation in the RoboCopy.exe version. On the right-hand-side you will find a screenshot showing the properties of my homefolder. This also shows a small deviation. This deviation seems to be the result of a growing VHD file in my homefolder. I'll list to RoboCopy parameters for reference:

  • /L - List only
  • /XJ - Do not follow NTFS junctions
  • /R:0 - Retries 0
  • /W:1 - Wait 1 sec before retry
  • /NP - Don't display progress
  • /E - Include empty folders
  • /BYTES - Display output in bytes (not supported on pre Win7 RoboCopy versions)
  • /NFL /NDL - No file and No directory listing
  • /MT:64 - Use 64 threads

Measuring the Dir Size calculations

So how fast are these commands actually? Which command should we use? Let's use Measure-Command to find out:

There you go Dir.exe is times faster than Get-ChildItem on my notebook with SSD. RoboCopy.exe is times faster.

Warning BUGS!

We found a bug when using DIR over PowerShell Remoting. After some fiddling around it appears as DIR get's into an infinite loop when recursively listing 'C:\Users\Username\AppData\Local\Application Data\'. When running in a local PowerShell session DIR will not try to follow the NTFS Junction. We've been able to reproduce this issue on Windows 2008, 2012R2 and on 2016TP5.

When executing locally:

When executing over PSR:

When I have some extra time on my hands I will transform this into a TreeSize module. Thanks again to @JaapBrasser for working on this with me!

Leave a Comment

Your email address will not be published. Required fields are marked *