[Q]Speediest way to count files?

[jwoegerbauer]

To count the files in %SYSTEMROOT% ( C:\Windows ) I tried 2 algorithms. Both took up the nearly equal amount of time: ~30 secs for 200,977 files. So at 1st glance it seems to be a matter of taste which one to use.

Code: Select all

@echo off
setlocal EnableDelayedExpansion
set tmp=%TEMP%\dircount.txt
::
:: Algorithm 1
::
echo(
echo algorithm 1
set /a count=0
echo %TIME%
dir "%SYSTEMROOT%\*.*" /b /s /adhsr /a-d > %tmp%
for /f %%a in (%tmp%) do (set /a count+=1)
set tme=%TIME%
echo %count%
echo %tme%
echo(
::
:: Algorithm 2
::
echo(
echo algorithm 2
SET /a count=0
set tmp2=%TEMP%\dircount2.txt
echo %TIME%
dir "%SYSTEMROOT%\*.*" /b /s /adhsr /a-d > %tmp%
findstr /n ^^ %tmp% > %tmp2%
(
   for /f "usebackq delims=" %%a in ("%tmp2%") do (
      set /a count+=1
   )
) > NUL
set tme=%TIME%
echo %count%
echo %tme%
echo(
::
::
pause
del "%tmp%" > NUL 2>&1
del "%tmp2%" > NUL 2>&1
endlocal
exit /b

My today's question: Is there a way to get it faster?

[foxidrive]

This is one way, if I understand your aim.

Code: Select all

dir "%systemroot%" /b /s /a-d |find /c /v "" 

EDIT: I added a missing quote.

[aGerman]

The total number of files isn't already saved in the properties of a folder. Even if you right-click on a folder to show its properties you will see that the number of files and the size will be slowly counted up until everything is processed. This may take several seconds depending on the structure of the folder.
Thus, the answer is that you might be able to increase the speed by optimizing the computing of DIRs output (see foxydrives answer). But probably it won't make a big difference because the DIR command itself is what the process slows down since it has to iterate over the whole folder structure recursively.

Regards
aGerman

[foxidrive]

the DIR command itself is what the process slows down since it has to iterate over the whole folder structure recursively.

This is true - and the disk cache is most likely involved too.
The second time etc that you run the code may be faster because there is data that is being read out of the cache rather than the physical drive.

The access speed of drive is another factor - a large modern HDD will return a faster result than an old small HDD, and an SSD will be faster again, given the same set of files in the tree.

[jwoegerbauer]

The total number of files isn't already saved in the properties of a folder. Even if you right-click on a folder to show its properties you will see that the number of files and the size will be slowly counted up until everything is processed. This may take several seconds depending on the structure of the folder.

That's it: horribly slow. Took ~ 2 minutes on my Windows 8.1.1 64-bit machine.

[penpen]

The monitoring overhead and the size of the pipe buffer (1024 characters) may be limitating, too (depends on the output size).
I assume the fastest should be using a second HDD (or better a ramdrive) and store the result of the dir output to disk and then run find on this file.

penpen