压缩算法问题

[micky-git]

对于一个1.12版本保存的，69.2MB大小16通道（11-16为空信号）的文件 1.12版本ziplib分通道多线程保存 29.5s存完，存盘后大小69.2MB 1.2版本m_opt_compress_level取1-9，同样多线程（4core/8thread）

level/filesize(MB)/time(S) 1/12.5MB/1.965s 2/115MB/1.9s 3/100.8MB/2.228s 4/100MB/3.0s 5/90.1MB/3.668s 6/78.8MB/5.792s 7/75.8MB/7.926s 8/71.5MB/13.50s 9/69.0MB/27.67s

最优m_opt_compress_level=3、4 原来算法的压缩瓶颈看起来不在磁盘读写 新的算法在内存中压缩在m_opt_compress_level=9下也只比原来快了10%

在CNT较大的时候存储边沿会比zip的lz77算法快很多。

[micky-git]

建议做一个流式存储的DSView 一边不停的采集，一边不停的压缩存盘，续接给一个大文件。

[dreamsource-tai]

@micky-git 新的库比libzip快的不只是一点点哦。

[micky-git]

@micky-git 新的库比libzip快的不只是一点点哦。 新的库确实比原来的快，但是主要的加速来自于降低了压缩率。

原来的库： 1.每次续一块buff，时间会越来越慢，按通道上台阶变慢（probe1<probe2<...）。 2.有时候一块buff会突然时间暴增5-10倍，可能是被读阻塞了，读然后checksum。 3.原来的库多线程之后这个问题会减小很多。因为不用所有块等它一块。

新的库我也改成多线程了，测试了速度，并且跟原来的库对比 我测下来新库相当于解决了块不稳定问题，同时牺牲压缩率换的速度。 同压缩率下跟原来库速度几乎一样（快10%）

我怀疑是因为： 1.zip压缩的算法第一步是lz77，第二步是霍夫曼编码。 2.对于比较稀疏的数据lz77压缩算法非常浪费时间，比如一个全0/1的2M空块lz77还是会压缩出一个100B左右的文件。 3.对于一个只有1个方波的2M的块，会压缩出一个10k左右的文件

[micky-git]

@micky-git 新的库比libzip快的不只是一点点哦。

你试试m_opt_compress_level=9是不是压缩出来的文件跟原来一样大，时间快了一点。