24

读取大型二进制文件（2-3 GB）的每 30 个字节的最快方法是什么？我已经读过 fseek 由于 I/O 缓冲区存在性能问题，但我也不想在抓取每 30 个字节之前将 2-3 GB 的数据读入内存。

4

7 回答 7

24

我建议您创建一个几千字节的缓冲区，从中读取每 30 个字节，用接下来的几千字节重新加载缓冲区，然后继续直到到达 eof。这样，读入内存的数据量是有限的，而且您也不必经常从文件中读取。您会发现创建的缓冲区越大，速度就越快。

编辑：实际上，如下所示，您可能希望将缓冲区设置为几百 kb，而不是几千字节（就像我说的 - 更大的缓冲区 = 更快的文件读取）。

于 2010-03-06T23:31:08.460 回答
17

性能测试。如果您想自己使用它，请注意完整性检查（打印总数）仅在“步”除 BUFSZ 并且 MEGS 足够小以至于您不会读取文件末尾时才有效。这是由于（a）懒惰，（b）不想掩盖真实代码。rand1.data 是从 /dev/urandom 使用dd.

#include <stdio.h>
#include <stdlib.h>

const long long size = 1024LL*1024*MEGS;
const int step = 32;

int main() {
    FILE *in = fopen("/cygdrive/c/rand1.data", "rb");
    int total = 0;
    #if SEEK
        long long i = 0;
        char buf[1];
        while (i < size) {
            fread(buf, 1, 1, in);
            total += (unsigned char) buf[0];
            fseek(in, step - 1, SEEK_CUR);
            i += step;
        }
    #endif
    #ifdef BUFSZ
        long long i = 0;
        char buf[BUFSZ];
        while (i < size) {
            fread(buf, BUFSZ, 1, in);
            i += BUFSZ;
            for (int j = 0; j < BUFSZ; j += step) 
                total += (unsigned char) buf[j];
        }
    #endif
    printf("%d\n", total);
}

结果：

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32*1024 -DMEGS=20 && time ./buff2
83595817

real    0m1.391s
user    0m0.030s
sys     0m0.030s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32 -DMEGS=20 && time ./buff2
83595817

real    0m0.172s
user    0m0.108s
sys     0m0.046s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32*1024 -DMEGS=20 && time ./buff2
83595817

real    0m0.031s
user    0m0.030s
sys     0m0.015s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32 -DMEGS=20 && time ./buff2
83595817

real    0m0.141s
user    0m0.140s
sys     0m0.015s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DSEEK -DMEGS=20 && time ./buff2
83595817

real    0m20.797s
user    0m1.733s
sys     0m9.140s

概括：

我最初使用 20MB 的数据，这当然适合缓存。我第一次读取它（使用 32KB 缓冲区）需要 1.4 秒，将其放入缓存中。第二次（使用 32 字节缓冲区）需要 0.17 秒。第三次（再次返回 32KB 缓冲区）需要 0.03 秒，这太接近我的计时器的粒度而没有意义。fseek 需要超过 20 秒，即使数据已经在磁盘缓存中。

在这一点上，我将 fseek 拉出环，以便其他两个可以继续：

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32*1024 -DMEGS=1000 && time ./buff2
-117681741

real    0m33.437s
user    0m0.749s
sys     0m1.562s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32 -DMEGS=1000 && time ./buff2
-117681741

real    0m6.078s
user    0m5.030s
sys     0m0.484s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32*1024 -DMEGS=1000 && time ./buff2
-117681741

real    0m1.141s
user    0m0.280s
sys     0m0.500s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32 -DMEGS=1000 && time ./buff2
-117681741

real    0m6.094s
user    0m4.968s
sys     0m0.640s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32*1024 -DMEGS=1000 && time ./buff2
-117681741

real    0m1.140s
user    0m0.171s
sys     0m0.640s

1000MB 的数据似乎也被大量缓存。32KB 缓冲区比 32 字节缓冲区快 6 倍。但区别在于所有用户时间，而不是阻塞在磁盘 I/O 上的时间。现在，8000MB 比我的 RAM 多得多，所以我可以避免缓存：

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32*1024 -DMEGS=8000 && time ./buff2
-938074821

real    3m25.515s
user    0m5.155s
sys     0m12.640s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32 -DMEGS=8000 && time ./buff2
-938074821

real    3m59.015s
user    1m11.061s
sys     0m10.999s

$ gcc -std=c99 buff2.c -obuff2 -O3 -DBUFSZ=32*1024 -DMEGS=8000 && time ./buff2
-938074821

real    3m42.423s
user    0m5.577s
sys     0m14.484s

忽略这三个中的第一个，它受益于文件的前 1000MB 已经在 RAM 中。

现在，32KB 的版本在挂钟时间上只是稍微快了一点（我懒得重新运行，所以我们暂时忽略它），但是看看用户+系统时间的差异：20s vs. 82 秒。我认为我的操作系统的推测性预读磁盘缓存在这里保存了 32 字节缓冲区的培根：虽然 32 字节缓冲区正在缓慢重新填充，但操作系统正在加载接下来的几个磁盘扇区，即使没有人要求它们。如果没有它，我怀疑它会比 32KB 缓冲区慢一分钟 (20%)，后者在请求下一次读取之前在用户空间中花费的时间更少。

故事的寓意：标准 I/O 缓冲并没有在我的实现中削减它，正如提问者所说， fseek 的性能很糟糕。当文件缓存在操作系统中时，缓冲区大小很重要。当文件未缓存在操作系统中时，缓冲区大小对挂钟时间没有太大影响，但我的 CPU 更忙。

incrediman 使用读取缓冲区的基本建议至关重要，因为 fseek 令人震惊。在我的机器上争论缓冲区应该是几 KB 还是几百 KB 很可能毫无意义，可能是因为操作系统已经完成了确保操作严格 I/O 绑定的工作。但我很确定这取决于 OS 磁盘预读，而不是标准 I/O 缓冲，因为如果是后者，那么 fseek 会比现在更好。实际上，可能是标准 I/O 正在执行预读，但是 fseek 的一个过于简单的实现是每次都丢弃缓冲区。我还没有研究过实现（如果我这样做了，我也无法跨越边界进入操作系统和文件系统驱动程序）。

于 2010-03-07T05:01:36.687 回答
10

好吧，您可以读取一个字节，然后在循环中查找 29 个字节。但是 IO 子系统必须按扇区读取文件，通常大小为 512 字节，因此它最终仍会读取整个文件。

从长远来看，以步长倍数的块读取整个文件会更快，然后只查看缓冲区。如果你确保缓冲区大小是 30 的倍数，你会让你的生活变得更简单，如果它是 512 的倍数，你会让 fileio 子系统的生活更轻松。 

while (still more file to read)
{ 
   char buf[30 * 512];
   int cread = fread (buf, sizeof(buf), 1, fd);
   for (int ii = 0; ii < cread; ii += 30)
   {

   }
}

这可能看起来效率低下，但它会比尝试读取 30 字节块更快。

顺便一提。如果您在 Windows 上运行，并且愿意特定于操作系统，那么您真的无法击败内存映射文件的性能。 如何扫描磁盘上非常大的文件？

于 2010-03-06T23:39:20.657 回答
9

如果您愿意脱离 ANSI-C 并使用特定于操作系统的调用，我建议您使用内存映射文件。这是 Posix 版本（Windows 有自己的操作系统特定调用）：

#define MAPSIZE 4096
int fd = open(file, O_RDONLY);
struct stat stbuf;
fstat(fd, &stbuf);


char *addr = 0;
off_t last_mapped_offset = -1;
off_t idx = 0;
while (idx < stbuf.st_size)
{
    if (last_mapped_offset != (idx / MAPSIZE))
    {
        if (addr)
            munmap(addr, MAPSIZE);

        last_mapped_offset = idx / MAPSIZE; 

        addr = mmmap(0, MAPSIZE, PROT_READ, MAP_FILE, fd, idx, last_mapped_offset);
    }

    *(addr + (idx % MAPSIZE));

    idx += 30;

}

munmap(addr, MAPSIZE);
close(fd);
于 2010-03-06T23:43:29.310 回答
3

缓冲 I/O 库的全部目的就是让您摆脱这些顾虑。如果您必须每 30 个字节读取一次，那么操作系统将最终读取整个文件，因为操作系统会读取更大的块。以下是您的选项，从最高性能到最低性能：

  • 如果您的地址空间很大（即，您在 64 位硬件上运行 64 位操作系统），那么使用内存映射 IO（mmap在 POSIX 系统上）将为您节省让操作系统从内核复制数据的成本空间到用户空间。这种节省可能非常可观。

  • 如下面的详细说明所示（感谢 Steve Jessop 的基准测试），如果您关心 I/O 性能，您应该从 AT&T 高级软件技术组下载 Phong Vo 的sfio 库。它比 C 的标准 I/O 库更安全、设计更好、速度更快。在使用fseek很多的程序上，它的速度要快得多：在一个简单的微基准测试上快七倍。

  • 只需放松并使用fseekand fgetc，它们的设计和实施正是为了解决您的问题。

如果你认真对待这个问题，你应该衡量所有三个备选方案。Steve Jessop 和我展示了使用fseek速度较慢，如果您使用的是 GNU C 库，fseek则速度要慢得多。你应该测量mmap；它可能是最快的。

附录：您想查看您的文件系统并确保它可以快速从磁盘中提取 2-3 GB。例如，XFS 可能会击败 ext2。当然，如果您坚持使用 NTFS 或 HFS+，它只会变慢。

令人震惊的结果

我重复了 Steve Jessop 在 Linux 上的测量。GNU C 库在每个fseek. 除非 POSIX 出于某种原因需要这样做，否则这太疯狂了。我可以咀嚼一堆 1 和 0，然后吐出一个比这更好的缓冲 I/O 库。无论如何，成本增加了大约 20 倍，其中大部分花费在内核中。如果您使用fgetc而不是fread读取单个字节，则可以在小型基准测试中节省大约 20%。

体面的 I/O 库带来的结果不那么令人震惊

我又做了一次实验，这次使用的是 Phong Vo 的sfio图书馆。读取 200MB 需要

  • 0.15s 不使用fseek（BUFSZ是 30k）
  • 0.57s 使用fseek

反复测量表明，不fseek使用 sfio 时，运行时间仍会减少约 10%，但运行时间非常嘈杂（几乎所有时间都花在了操作系统上）。

在这台机器（笔记本电脑）上，我没有足够的可用磁盘空间来运行不适合磁盘缓存的文件，但我愿意得出以下结论：

  • 使用合理的 I/O 库fseek会更昂贵，但不足以产生重大影响（如果您所做的只是 I/O，则需要 4 秒）。

  • GNU 项目不提供合理的 I/O 库。通常情况下，GNU 软件很烂。

结论：如果您想要快速 I/O，您的第一步应该是用 AT&T sfio 库替换 GNU I/O 库。相比之下，其他影响可能很小。

于 2010-03-07T02:52:02.000 回答
1

你几乎可以肯定不需要担心它。运行时可以很好地缓冲它为每个文件句柄读取的最后一个块。即使没有，操作系统也会为您缓存文件访问。

也就是说，如果您一次读取一个块，您确实可以节省 fseek 和 fread 函数的调用开销。您一次阅读的块越大，您节省的通话费用就越多——尽管其他成本显然开始让自己感觉超出了某个点。

于 2010-03-07T00:21:50.357 回答
0

如果您从带有旋转盘片的硬盘读取数据，答案是您使用大缓冲区顺序读取整个文件并丢弃内存中不需要的部分。

对标准硬盘驱动器的最小访问单位是扇区。所有常见的旋转磁盘驱动器的扇区大小都超过 30 字节。这意味着无论来自主机的请求是什么样的，硬盘控制器都必须访问每个扇区。没有低级魔法可以改变这一点。

即使不是这种情况，并且您可以读取单个字节，查找操作与顺序读取操作相比也存在巨大的溢价。最好的情况仍然与顺序读取相同。在现实世界中，如果信令开销会阻止此类方案即使使用大量命令缓冲区也无法工作，我不会感到惊讶。

于 2010-06-19T22:28:59.870 回答