您需要对其进行性能剖析,以确定瓶颈所在。
也许它在内核中,也许您已经达到了硬件的极限。 在您进行性能剖析之前,您将摸索在黑暗中。
编辑:
好的,这次回答更详细一些。根据 Boost.Iostreams 文档,basic_file_source
仅是 std::filebuf
的一个包装器,而 std::filebuf
又是基于 std::streambuf
构建的。引用文档:
可复制构造和可赋值封装器,用于 std::basic_filebuf 的只读模式打开。
streambuf
提供了一个方法 pubsetbuf (可能不是最好的参考,但第一个谷歌搜索结果),您可以使用它来控制缓冲区大小。
例如:
#include <fstream>
int main()
{
char buf[4096];
std::ifstream f;
f.rdbuf()->pubsetbuf(buf, 4096);
f.open("/tmp/large_file", std::ios::binary);
while( !f.eof() )
{
char rbuf[1024];
f.read(rbuf, 1024);
}
return 0;
}
在我的测试中(关闭优化),使用4096字节缓冲区的性能实际上比使用16字节缓冲区的性能更差,但是你的情况可能不同 -- 这是为什么你应该始终先进行分析的好例子 :)
但正如你所说,
basic_file_sink
没有提供任何访问方式,因为它在其
私有部分隐藏了底层的
filebuf
。
如果您认为这是错误的,您可以:
- 敦促Boost开发人员公开此类功能,使用邮件列表或trac。
- 构建自己的
filebuf
包装器,它确实公开了缓冲区大小。教程中有一个章节解释了编写自定义源代码的方法,这可能是一个很好的起点。
- 基于任何内容编写自定义源代码,以执行您想要的所有缓存操作。
请记住,您的硬盘以及内核已经对文件读取进行了缓存和缓冲处理,我认为即使从缓存更多数据,也不会获得太多的性能提升。
最后,关于分析的话题。对于Linux,有大量强大的分析工具可用,我甚至不知道其中一半的名称,但例如有
iotop,它非常简单易用。它几乎就像top,但显示与磁盘相关的指标。例如:
Total DISK READ: 31.23 M/s | Total DISK WRITE: 109.36 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
19502 be/4 staffan 31.23 M/s 0.00 B/s 0.00 % 91.93 % ./apa
告诉我,我的程序超过90%的时间都花在等待IO上,也就是说它是IO密集型的。如果你需要更强大的工具,我相信谷歌可以帮助你。
还要记住,在热缓存或冷缓存上进行基准测试会极大地影响结果。