读取文件长度最快的方法C#

jpi*_*s14 23 .net c# filestream

我使用的fs.Length,这里fs是一个FileStream.

这是一个O(1)手术吗?我认为这只会从文件的属性中读取,而不是通过文件来查找搜索位置到达结尾的时间.我试图找到长度的文件可以很容易地从1 MB到4-5 GB.

但是我注意到有一个FileInfo类,它也有一个Length属性.

Length理论上这两个属性是否需要相同的时间?或者确实fs.Length较慢,因为它必须打开第FileStream一个?

ken*_*n2k 35

.NET中获取文件大小的自然方法是您提到的FileInfo.Length属性.

我不确定Stream.Length是否较慢(它无论如何都不会读取整个文件),但如果你不打算读取文件,那么使用它FileInfo代替a 肯定更自然FileStream.


这是一个提供一些数值的小基准:

private static void Main(string[] args)
{
    string filePath = ...;   // Path to 2.5 GB file here

    Stopwatch z1 = new Stopwatch();
    Stopwatch z2 = new Stopwatch();

    int count = 10000;

    z1.Start();
    for (int i = 0; i < count; i++)
    {
        long length;
        using (Stream stream = new FileStream(filePath, FileMode.Open))
        {
            length = stream.Length;
        }
    }

    z1.Stop();

    z2.Start();
    for (int i = 0; i < count; i++)
    {
        long length = new FileInfo(filePath).Length;
    }

    z2.Stop();

    Console.WriteLine(string.Format("Stream: {0}", z1.ElapsedMilliseconds));
    Console.WriteLine(string.Format("FileInfo: {0}", z2.ElapsedMilliseconds));

    Console.ReadKey();
}
Run Code Online (Sandbox Code Playgroud)

结果:

Stream: 886
FileInfo: 727
Run Code Online (Sandbox Code Playgroud)

  • 以这种方式进行基准测试可能不是测试差异的最有效方法(如果存在)。我认为磁盘缓存/操作系统因素将在减少时间方面发挥重要作用。 (2认同)
  • @PaulG 你说得对。基准测试**总是**比看起来更复杂。**only** 上面的简单基准给出了有关实际结果的_一些迹象_。由于它没有返回 100000 vs 250,我认为可以得出结论,这两种方法_没有太大不同_(就计算时间而言)。 (2认同)

Jon*_*eet 28

两者都将访问文件系统元数据而不是读取整个文件.我不知道这是更有效的必然,作为一个经验法则我会说,如果你只是想知道的长度(和其他元数据),使用FileInfo-而如果你反正打开该文件作为流,用FileStream.Length.