使用C#,我正在查找目录的总大小。逻辑是这样的:获取文件夹内的文件。求出总大小。查找是否有子目录。然后进行递归搜索。
我尝试了另一种方法:使用FSO(obj.GetFolder(path).Size
)。在这两种方法中,时间上没有太大差异。
现在的问题是,某个特定文件夹中有数万个文件,需要至少2分钟才能找到文件夹的大小。而且,如果我再次运行程序,它就会非常快(5秒)。我认为Windows正在缓存文件大小。
当我第一次运行程序时,有没有办法缩短所需的时间?
使用C#,我正在查找目录的总大小。逻辑是这样的:获取文件夹内的文件。求出总大小。查找是否有子目录。然后进行递归搜索。
我尝试了另一种方法:使用FSO(obj.GetFolder(path).Size
)。在这两种方法中,时间上没有太大差异。
现在的问题是,某个特定文件夹中有数万个文件,需要至少2分钟才能找到文件夹的大小。而且,如果我再次运行程序,它就会非常快(5秒)。我认为Windows正在缓存文件大小。
当我第一次运行程序时,有没有办法缩短所需的时间?
如果您尝试并行化它,而且出乎意料的是,在我的机器上加速了(在四核上高达3倍),不知道在所有情况下是否有效,但可以尝试一下...
.NET4.0代码(或使用TaskParallelLibrary的3.5版本)
private static long DirSize(string sourceDir, bool recurse)
{
long size = 0;
string[] fileEntries = Directory.GetFiles(sourceDir);
foreach (string fileName in fileEntries)
{
Interlocked.Add(ref size, (new FileInfo(fileName)).Length);
}
if (recurse)
{
string[] subdirEntries = Directory.GetDirectories(sourceDir);
Parallel.For<long>(0, subdirEntries.Length, () => 0, (i, loop, subtotal) =>
{
if ((File.GetAttributes(subdirEntries[i]) & FileAttributes.ReparsePoint) != FileAttributes.ReparsePoint)
{
subtotal += DirSize(subdirEntries[i], true);
return subtotal;
}
return 0;
},
(x) => Interlocked.Add(ref size, x)
);
}
return size;
}
硬盘是一个有趣的动物 - 顺序访问(例如读取一个大的连续文件)非常快,可达80兆字节/秒。然而,随机访问非常慢。这就是你遇到的问题 - 递归进入文件夹不会读取太多(在数量方面)数据,但需要许多随机读取。第二次运行看到快速表现的原因是MFT仍然在RAM中(你对缓存的想法是正确的)
我见过的最好的方法是自己扫描MFT。理念是你一次线性地读取和解析MFT,构建你需要的信息。最终结果将更接近于在一个非常满的硬盘上花费15秒。
一些好的阅读材料: NTFSInfo.exe - http://technet.microsoft.com/en-us/sysinternals/bb897424.aspx Windows Internals - http://www.amazon.com/Windows®-Internals-Including-Windows-PRO-Developer/dp/0735625301/ref=sr_1_1?ie=UTF8&s=books&qid=1277085832&sr=8-1
顺便说一句:这种方法非常复杂,因为在Windows(或我知道的任何操作系统)中没有一个很好的方法来解决这个问题 - 问题是找出哪些文件夹/文件是必需的需要磁盘上的大量头部移动。对于微软来说,要建立一个解决你描述的问题的通用解决方案是非常困难的。
当扫描包含数万个文件的文件夹时,使用任何方法都会导致性能下降。
使用Windows API中的FindFirstFile...和FindNextFile...函数可以提供最快的访问速度。
由于调用开销,即使使用Windows API函数,性能也不会提高。框架已经封装了这些API函数,因此自己做没有意义。
无论使用哪种文件访问方法,如何处理结果都决定了应用程序的性能。例如,即使使用Windows API函数,更新列表框就会导致性能下降。
您不能将执行速度与Windows资源管理器进行比较。根据我的实验,我认为Windows资源管理器在许多情况下直接从文件分配表中读取。
我知道最快访问文件系统的方法是使用DIR
命令。您不能将性能与此命令进行比较。它肯定直接从文件分配表中读取(可能使用BIOS)。
是的,操作系统缓存文件访问。
我想知道BackupRead
是否可以在您的情况下有所帮助?
如果您调用DIR并捕获并解析其输出,会怎样?(您实际上并未解析,因为每个DIR行都是固定宽度,所以只需要调用子字符串。)
如果您在后台线程中调用DIR /B > NULL
然后运行程序会怎样?在DIR运行时,您将从缓存的文件访问中受益。
GetFileSystemInfos
和GetDirectories
,您会发现执行相同的操作更频繁,包括大量的CloseFile
和CreateFile
操作。这些.NET方法调用API例程。因此,您可以推断DIR命令没有调用这些API函数。 - AMissico根据spookycoder的回答,我发现这种变体(使用DirectoryInfo
)至少快了2倍(在复杂的文件夹结构上高达10倍!):
public static long CalcDirSize(string sourceDir, bool recurse = true)
{
return _CalcDirSize(new DirectoryInfo(sourceDir), recurse);
}
private static long _CalcDirSize(DirectoryInfo di, bool recurse = true)
{
long size = 0;
FileInfo[] fiEntries = di.GetFiles();
foreach (var fiEntry in fiEntries)
{
Interlocked.Add(ref size, fiEntry.Length);
}
if (recurse)
{
DirectoryInfo[] diEntries = di.GetDirectories("*.*", SearchOption.TopDirectoryOnly);
System.Threading.Tasks.Parallel.For<long>(0, diEntries.Length, () => 0, (i, loop, subtotal) =>
{
if ((diEntries[i].Attributes & FileAttributes.ReparsePoint) == FileAttributes.ReparsePoint) return 0;
subtotal += __CalcDirSize(diEntries[i], true);
return subtotal;
},
(x) => Interlocked.Add(ref size, x)
);
}
return size;
}
我认为它不会有太大的变化,但如果您使用API函数FindFirstFile
和NextFile
来完成它,它可能会快一点。
然而,我认为没有真正快速的方法。为了比较,您可以尝试在Windows资源管理器中列出目录,或者使用dir /a /x /s > dirlist.txt
命令,看看它们的速度如何,但我认为它们与FindFirstFile
类似。
PInvoke提供了如何使用API的示例。
出于性能原因,我放弃了 .NET 实现,并使用本地函数 GetFileAttributesEx(...)。
试试这个:
[StructLayout(LayoutKind.Sequential)]
public struct WIN32_FILE_ATTRIBUTE_DATA
{
public uint fileAttributes;
public System.Runtime.InteropServices.ComTypes.FILETIME creationTime;
public System.Runtime.InteropServices.ComTypes.FILETIME lastAccessTime;
public System.Runtime.InteropServices.ComTypes.FILETIME lastWriteTime;
public uint fileSizeHigh;
public uint fileSizeLow;
}
public enum GET_FILEEX_INFO_LEVELS
{
GetFileExInfoStandard,
GetFileExMaxInfoLevel
}
public class NativeMethods {
[DllImport("KERNEL32.dll", CharSet = CharSet.Auto)]
public static extern bool GetFileAttributesEx(string path, GET_FILEEX_INFO_LEVELS level, out WIN32_FILE_ATTRIBUTE_DATA data);
}
现在只需执行以下操作:
WIN32_FILE_ATTRIBUTE_DATA data;
if(NativeMethods.GetFileAttributesEx("[your path]", GET_FILEEX_INFO_LEVELS.GetFileExInfoStandard, out data)) {
long size = (data.fileSizeHigh << 32) & data.fileSizeLow;
}
如果有成千上万个文件,你不可能通过正面攻击获胜。你需要尝试更具创造性的解决方案。有这么多的文件,你甚至可能会发现,在计算大小的时间内,文件已经发生了变化,你的数据已经错误了。
所以,你需要将负载移动到其他地方。对我来说,答案是使用System.IO.FileSystemWatcher
并编写一些代码来监视目录并更新索引。
编写一个Windows服务只需要很短的时间,可以配置为监视一组目录并将结果写入共享输出文件。您可以让服务在启动时重新计算文件大小,但然后只需在System.IO.FileSystemWatcher
触发Create/Delete/Changed事件时监视更改即可。监视目录的好处是,您只关心小的更改,这意味着您的数字更有可能是正确的(记住所有数据都是陈旧的!)
然后,唯一需要注意的是,您将有多个资源都尝试访问生成的输出文件。因此,请确保考虑到这一点。