Question

使用C＃，我找到目录的总大小。逻辑是这样的：获取文件夹中的文件。总结总大小。查找是否有子目录。然后进行递归搜索。

我也尝试了另外一种方法：使用FSO（obj.GetFolder(path).Size）。这两种方法的时间差别不大。

现在的问题是，我在特定文件夹中有成千上万的文件，并且至少需要2分钟才能找到文件夹大小。此外，如果我再次运行程序，它会很快发生（5秒）。我认为窗口正在缓存文件大小。

有没有什么方法可以减少我第一次运行程序所花费的时间？

Answer 1

如果摆弄它一段时间，尝试并行化它，并且令人惊讶 - 它在我的机器上加速（在四核上最多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;
    }

Answer 2

硬盘是一个有趣的野兽 - 顺序访问（例如读取一个大的连续文件）是超级活泼的，如图80兆字节/秒。但是随机访问非常慢。这就是你要碰到的东西 - 递归到文件夹中不会读取太多（就数量而言）数据，但需要许多随机读取。你第二次看到zippy perf的原因是因为MFT仍然在RAM中（你在缓存思想上是正确的）

我见过的最好的机制是自己扫描MFT。我们的想法是，您可以在一个线性传递中阅读和解析MFT，从而构建您需要的信息。对于非常饱满的高清，最终结果将更接近15秒。

一些好的阅读： NTFSInfo.exe - http://technet.microsoft.com/en-us/sysinternals/bb897424.aspx Windows Internals - http://www.amazon.com/Windows%C2%AE-Internals-Including-Windows-PRO-Developer/dp/0735625301/ref=sr_1_1?ie=UTF8&s=books&qid=1277085832&sr=8-1

FWIW：这个方法非常复杂，因为在Windows（或我所知道的任何操作系统）中确实没有很好的方法 - 问题在于找出需要哪些文件夹/文件的行为在磁盘上需要很多磁头移动。微软很难为你描述的问题建立一个通用的解决方案。

Answer 3

简短的回答是否定的。 Windows可以使目录大小计算更快的方式是更新每个文件写入的目录大小和所有父目录大小。但是，这会使文件写入操作变慢。由于文件写入比读取目录大小更常见，因此这是一个合理的权衡。

我不确定究竟是什么问题正在解决，但如果是文件系统监控则可能值得一试：http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx

Answer 4

我认为它不会发生太大变化，但如果您使用API函数FindFirstFile和NextFile来实现它可能会更快一些。

我认为没有任何真正快速的方法。为了进行比较，您可以尝试执行dir /a /x /s > dirlist.txt并在Windows资源管理器中列出目录以查看它们的速度，但我认为它们与FindFirstFile类似。

PInvoke有一个如何使用API的示例。

Answer 5

在扫描包含数万个文件的文件夹时，使用任何方法。

使用Windows API FindFirstFile ...和FindNextFile ...函数提供最快的访问权限。

由于编组开销，即使您使用Windows API函数，性能也不会提高。框架已经包装了这些API函数，因此没有意义自己做。

如何处理任何文件访问方法的结果会决定应用程序的性能。例如，即使您使用Windows API函数，更新列表框也会影响性能。

您无法将执行速度与Windows资源管理器进行比较。从我的实验中，我相信在很多情况下，Windows资源管理器会直接从文件分配表中读取。

我知道对文件系统的最快访问是DIR命令。您无法将性能与此命令进行比较。它肯定直接从文件分配表中读取（可能使用BIOS）。

是的，操作系统会缓存文件访问权限。

建议

我想知道BackupRead是否有助于你的案件？

如果您对DIR进行shell并捕获然后解析其输出怎么办？（你不是真正解析，因为每个DIR行都是固定宽度的，所以这只是调用子字符串的问题。）

如果你在后台线程上发送DIR /B > NULL然后运行你的程序怎么办？在DIR运行时，您将受益于缓存的文件访问。

Answer 6

拥有成千上万的文件，你不会以正面攻击赢得胜利。您需要尝试使用该解决方案更具创造性。有了这么多文件，您甚至可能会发现在计算大小的时候，文件已经改变，而且数据已经错了。

因此，您需要将负载移至其他位置。对我来说，答案是使用System.IO.FileSystemWatcher并编写一些监视目录并更新索引的代码。

编写可以配置为监视一组目录并将结果写入共享输出文件的Windows服务只需要很短的时间。您可以让服务在启动时重新计算文件大小，但只要在System.IO.FileSystemWatcher触发创建/删除/更改事件时监视更改。监控目录的好处是你只对小变化感兴趣，这意味着你的数字更有可能是正确的（记住所有数据都是陈旧的！）

然后，唯一要注意的是，您将有多个资源都试图访问生成的输出文件。所以请确保考虑到这一点。

Answer 7

我放弃了.NET实现（出于性能原因）并使用了Native函数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;
}

Answer 8

根据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;
    }

目录文件大小计算 - 如何使其更快？

8 个答案:

建议