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 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 $$\frac{55468}{14617}\approx3.79$$ times faster than Get-ChildItem on my notebook with SSD. RoboCopy.exe is $$\frac{55468}{2941}\approx18.86$$ 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!