你处于不利地位。
Windows资源管理器几乎可以肯定地使用
FindFirstFile/
FindNextFile遍历目录结构
并
lpFindFileData一次通过（通过）收集大小信息，从而使每个文件实质上是一个系统调用。
不幸的是，在这种情况下，Python不是您的朋友。从而，
os.walk
首次通话os.listdir
（内部通话FindFirstFile
/FindNextFile
）- 从此以后进行的任何其他系统调用只会使您 比Windows资源管理器 慢
os.walk
然后调用isdir
返回的每个文件os.listdir
（在内部调用GetFileAttributesEx
-或在Win2k之前调用GetFileAttributes
+FindFirstFile
组合）以重新确定是否递归os.walk
和os.listdir
将执行 额外的内存分配 ，串和阵列操作等填写它们的返回值- 然后
getsize
，您需要 调用 返回的每个文件os.walk
（ 再次 调用GetFileAttributesEx
）
与Windows资源管理器相比，每个文件的系统调用多3倍，外加内存分配和操作开销。
您可以使用Anurag的解决方案，也可以尝试直接
FindFirstFile/
FindNextFile递归调用/
（应该与a
cygwin或其他win32端口
的性能相当
du -s some_directory）。
请参阅
os.py的实施
os.walk，
posixmodule.c为实施
listdir和
win32_stat（双方调用
isdir和
getsize。）
请注意， os.walk
在所有平台（Windows和 nices） 上 ，Python 在所有版本
（包括Python3.1）以下 都是次优的 。在Windows和
nices上
os.walk都可以通过遍历而无需调用，
isdir因为
FindFirst/
FindNext（Windows）和
opendir/
readdir（
nix）已经通过
lpFindFileData->dwFileAttributes（Windows）和
dirent::d_type（
nix）返回了文件类型。
可能违反直觉，在大多数现代配置（例如Win7和NTFS，甚至某些SMB实现）
GetFileAttributesEx上 ，
其速度
FindFirstFile是单个文件的 两倍 （可能比。遍历目录还要慢
FindNextFile）。
更新： Python 3.5包括新的PEP 471
os.scandir()函数，该函数通过返回文件属性和文件名来解决此问题。此新功能用于加快内置速度
os.walk()（在Windows和Linux上）。您可以在PyPI上使用scandir模块来获得针对旧版Python版本（包括2.x）的此行为。
