你处于不利地位。
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)的此行为。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)