rongekuta

@sisong 看了hdiff的block 模式的算法， block算出来的指纹值 进行后缀排序， 采用了最基本的sort排序 复杂度应该是N^2 logN， 是否可以进行优化？ 比如采用 倍增法 （看样子因为int32 的值域远大于 ascii ， 其他的后缀排序算法未必能直接扩展支持int32）

@sisong good job！ 看来拓展的倍增法性能并没有期望的好， 我研究研究下基于block的优化，我曾经设想过利用重复数据删除技术中的基于内容的切分方式来优化，但是看起来内存也很大，也很复杂。 最近的测试给了我一些想法（也许利用Rabin–Karp 算法 比后缀数组更快）： 有位同事提到了 zstd 也支持patch模式 https://github.com/facebook/zstd/wiki/Zstandard-as-a-patching-engine 我对比了HDiff 和 zstd的压缩效果和性能（在我的centos 虚拟机上） 表1 算法patch时间与效果 文件 Hdiff patch时间 Zstd patch时间 Hdiff patch文件大小 Zstd patch文件大小 test1.obb（32MB） 5.7 秒...

> @rongekuta > > * hdiffz 的时候加了 -m-1 -p-1 -cache -d -c-zstd 参数吗? 这样对比更有可比性一些 > * hdiffz 除了默认的-m匹配模式，还支持-s匹配模式， -m-1 换成 -s-16 参数再测试看看 > * hdiffz 的时候加了 -m-1 -p-1 -cache -d...

@sisong 冒昧谈谈我的想法： 因为hdiff的内存限制机制 还有可扩展框架 适合 移动设备使用 在hdiff上尝试 rabin-karp 看看性能是否更好？ 想法是遍历old文件采用固定长度（8字节）计算hash值，存到hash表， 此时我们并不需要把所有的hash值都存到里边，可以采用一定采样机制，稀疏化，降低hash的冲突 并让hash表可以适当缩小。 new文件也进行滑块hash，并在hash表中查找，并且匹配 这样计算量是O（n）的 思路除了后缀排序有点类似 hdiff 的block模式， 应该在博客中你也谈到了这个思路，但是考虑到hash表内存占用，没有利用这个思路。 我猜测采用稀疏采样， 未必效果有大的下降，同时性能应该不差后缀排序

@sisong 你说的随机访问问题确实存在，大规模文件，采用细粒度的hash是会面临随机访问磁盘的问题，需要在上层加上一层分块机制；在重复数据删除也是这样两层设计； 当前我们文件大小限制是2GB（还没有达到上百GB）； 内存应该能用到 512MB zstd这方面为了性能采用全量加载内存； PS： 我在zstd提issue 看看 zstd是否存在改成 类似Hdiff文件缓存机制（ 不将 old文件（他们成为dict）全量加载内存）的可能性以及风险；

@jonashaag , yesterda. I set up vmprof-viewer-server according as https://github.com/blue-yonder/vmprof-viewer-server but meet a mistake: (env) [root@localhost vmprof-viewer-server]# vmprof_viewer/manage.py runserver Performing system checks... System check identified no issues (0 silenced). November...

i modify limitPatternLength and limitLiteralCount to 1MB， and use large pattern to compile, and found hyperscan compile is too slow