我正在运行一个程序来测试在包含大量文件的文件夹中查找和迭代所有文件的速度。该过程中最慢的部分是创建超过 100 万个文件。我目前正在使用一种非常幼稚的方法来创建文件：

Console.Write("Creating {0:N0} file(s) of size {1:N0} bytes... ", 
    options.FileCount, options.FileSize);
var createTimer = Stopwatch.StartNew();
var fileNames = new List<string>();
for (long i = 0; i < options.FileCount; i++)
{
    var filename = Path.Combine(options.Directory.FullName, 
                        CreateFilename(i, options.FileCount));
    using (var file = new FileStream(filename, FileMode.CreateNew, 
                        FileAccess.Write, FileShare.None, 4096, 
                        FileOptions.WriteThrough))
    {
        // I have an option to write some data to files, but it's not being used. 
        // That's why there's a using here.
    }
    fileNames.Add(filename);
}
createTimer.Stop();
Console.WriteLine("Done.");

// Other code appears here.....

Console.WriteLine("Time to  CreateFiles: {0:N3}sec ({1:N2} files/sec, 1 in {2:N4}ms)"
       , createTimer.Elapsed.TotalSeconds
       , (double)total / createTimer.Elapsed.TotalSeconds
       , createTimer.Elapsed.TotalMilliseconds / (double)options.FileCount);

Output:

Creating 1,000,000 file(s) of size 0 bytes... Done.
Time to  CreateFiles: 9,182.283sec (1,089.05 files/sec, 1 in 9.1823ms)

还有什么明显比这更好的吗？我想要测试大于 100 万个数量级的数据，但创建文件需要一天的时间！

我没有尝试任何形式的并行性，尝试优化任何文件系统选项或更改文件创建的顺序。

为了完整起见，以下是内容CreateFilename():

public static string CreateFilename(long i, long totalFiles)
{
    if (totalFiles < 0)
        throw new ArgumentOutOfRangeException("totalFiles", 
            totalFiles, "totalFiles must be positive");

    // This tries to keep filenames to the 8.3 format as much as possible.
    if (totalFiles < 99999999)
        // No extension.
        return String.Format("{0:00000000}", i);
    else if (totalFiles >= 100000000 && totalFiles < 9999999999)
    {
        // Extend numbers into extension.
        long rem = 0;
        long div = Math.DivRem(i, 1000, out rem);
        return String.Format("{0:00000000}", div) + "." + 
            String.Format("{0:000}", rem);
    }
    else
        // Doesn't fit in 8.3, so just tostring the long.
        return i.ToString();
}

UPDATE

尝试按照 StriplingWarrior 的建议进行并行化Parallel.For()。结果：大约 30 个线程对我的磁盘造成冲击，网络速度变慢！

        var fileNames = new ConcurrentBag<string>();
        var opts = new ParallelOptions();
        opts.MaxDegreeOfParallelism = 1;       // 1 thread turns out to be fastest.
        Parallel.For(0L, options.FileCount, opts,
            () => new { Files = new List<string>() },   
            (i, parState, state) =>
            {
                var filename = Path.Combine(options.Directory.FullName, 
                                   CreateFilename(i, options.FileCount));
                using (var file = new FileStream(filename, FileMode.CreateNew
                                  , FileAccess.Write, FileShare.None
                                  , 4096, FileOptions.WriteThrough))
                {
                }
                fileNames.Add(filename);
                return state;
            },
            state => 
            {
                foreach (var f in state.Files)
                {
                    fileNames.Add(f);
                }
            });
        createTimer.Stop();
        Console.WriteLine("Done.");

发现改变了FileOptions in the FileStream性能提高约 50%。看来我正在关闭任何写入缓存。

new FileStream(filename, FileMode.CreateNew, 
                 FileAccess.Write, FileShare.None, 
                 4096, FileOptions.None)

Results:

Creating 10,000 file(s) of size 0 bytes... Done.
Time to  CreateFiles: 12.390sec (8,071.05 files/sec, 1 in 1.2390ms)

其他想法仍然受欢迎。

这里最大的瓶颈无疑是你的硬盘。在一些快速测试中，我能够通过利用并行性看到一些显着的性能改进（但不是数量级）：

Parallel.For(1, 10000,
    i => File.Create(Path.Combine(path, i.ToString())));

有趣的是，至少在我的机器上，SSD 似乎对此操作没有太大影响。

• 在我的 HDD 上，上述代码在大约 31 秒内创建了 100,000 个文件。
• 在我的 SDD 上，上述代码在大约 33 秒内创建了 100,000 个文件。

Update

十年后，随着硬件和 .NET 6 的更新，我决定通过基准测试来测试几种不同的策略。LINQPad 脚本 http://share.linqpad.net/lulcoc.linq

令人惊讶的是，Parallel.For方法似乎需要大约 1/3 的时间。尝试通过 WriteAllTextAsync 利用并发性没有产生重大影响。