C BZ2_bz解压缩比bzip2命令慢

概述我正在使用mmap / read BZ2_bzDecompress来顺序解压缩大文件(29GB).这样做是因为我需要解析未压缩的xml数据,但只需要它的一小部分,看起来顺序执行此 *** 作比解压缩整个文件(400GB未压缩)然后解析它更有效.有趣的是,解压缩部分已经非常慢了 – 而 shell命令bzip2每秒能够执行超过52MB的 *** 作(使用多次超时运行10 bzip2 -c -k -d input.b 我正在使用mmap / read BZ2_bzDecompress来顺序解压缩大文件(29GB).这样做是因为我需要解析未压缩的xml数据,但只需要它的一小部分,看起来顺序执行此 *** 作比解压缩整个文件(400GB未压缩)然后解析它更有效.有趣的是,解压缩部分已经非常慢了 – 而 shell命令bzip2每秒能够执行超过52MB的 *** 作(使用多次超时运行10 bzip2 -c -k -d input.bz2>输出和分割生成的文件大小10),我的程序甚至不能达到2MB / s,几秒后减速到1.2MB / s

我正在尝试处理的文件使用多个bz2流,所以我正在检查BZ_S_bEAM_END的BZ2_bzDecompress,如果它发生,请使用BZ2_bzDecompressEnd(strm);如果文件尚未完全处理,则使用下一个流重新启动BZ2_bzDecompressInit(strm,0).我也试过没有BZ2_bzDecompressEnd,但没有改变任何东西(我在文档中没有真正看到如何正确处理多个流)

该文件之前是mmap’,在那里我也尝试了不同的标志组合,目前MAP_RDONLY,MAP_PRIVATE与madvise到MADV_SEQUENTIAL | MADV_WILLNEED | MADV_HUGEPAGE(我正在检查返回值,并且madvise没有报告任何问题,我正在使用linux内核3.2x debian设置,它具有巨大的页面支持)

在进行分析时,我确保除了一些用于测量速度的计数器和一个每n次迭代限制一次的printf之外,没有其他任何 *** 作.此外,这是在一个现代多核服务器处理器上,其中所有其他核心处于空闲状态,而且它是裸机,而不是虚拟化.

关于我可能做错什么/做什么以提高性能的任何想法？

更新：感谢James Chong的建议,我尝试用read()“交换”mmap(),速度仍然相同.所以似乎mmap()不是问题(或者mmap()和read()共享一个潜在的问题)

更新2：认为在bzDecompressInit / bzDecompressEnd中完成的malloc / free调用可能是原因,我将bz_stream结构的bzalloc / bzfree设置为自定义实现,该实现仅在第一次分配内存并且不释放它,除非标志是set(由opaque参数= strm.opaque传递).它工作得非常好,但速度并没有增加.

更新3：我现在也试过fread()而不是read(),但速度仍然保持不变.还尝试了不同数量的读取字节和解压缩数据缓冲区大小 – 没有变化.

更新4：读取速度绝对不是问题,因为我已经能够使用mmap()在顺序读取中实现接近约120MB / s的速度.

解决方法 交换,mmap标志与他们没什么关系.如果bzip2很慢,那不是因为文件I / O.

我认为你的libbz2没有完全优化.用你能想象的最残酷的gcc标志重新编译它.

我的第二个想法是,如果有一些ELF链接开销.在这种情况下,如果您静态链接bz2,问题将消失. (之后你将能够思考如何使用动态加载的libbz2来实现这一点).

未来的重要扩展：libbz2必须是可重入的,线程安全的和位置无关的.这意味着要编译的各种C标志,并且这些标志对性能没有很好的影响(尽管它们产生更快的代码).在一个极端情况下,我甚至可以想象,与单线程,非PIC,非重入版本相比,速度慢了5-10倍.

总结

以上是内存溢出为你收集整理的C BZ2_bz解压缩比bzip2命令慢全部内容，希望文章能够帮你解决C BZ2_bz解压缩比bzip2命令慢所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。