housisong
I like HDiffPatch , JojoDiff , bsdiff and xdelta3 for binary data Diff & Patch; HDiffPatch: https://github.com/sisong/HDiffPatch fast , create small differential; support large files; JojoDiff: https://sourceforge.net/p/jojodiff/code/ci/master/tree can generate very...
支持原地更新老数据
磁盘占用可控：下载的补丁包可能不能存储到磁盘,也需要原地更新老数据；（如果磁盘空间可用，patch执行又很快，那“边下载边patch”的需求不太可能单独存在） 内存占用可控：只下载一部分就开始执行补丁过程，分阶段完成patch过程； 缺点： - 原地更新老数据 的算法可行性还需要研究（已有初步可行结果，实现代码较复杂）； - 可能需要定义新的补丁数据格式更好，可能不利于压缩（现有格式也还能用）； - patch过程中，下载等失败不好复原（失败后业务上需要进入新旧替换更新，不能再使用补丁更新）；
当前的-m diff约一半以上时间消耗在后缀数组排序上；可以考虑并行实现。 一种是增加一个接口，支持外部用多线程环境并行调用；另外就是内置并行代码（当前的想法是同时支持单线程、openMP、pthread、C++11thread可选）；
相信会得到更小的diff数据;但这样代码就和不同平台的可执行程序文件结构有耦合,比如windows平台需要处理PE文件结构... 原理：1. 可执行文件在系统加载到内存的时候，能够加载到不同的基地址，这时系统会修正很多地址值；修正的原理正是我们可以利用(实现一个预处理算法)的地方... 2. 对于短跳转造成的diff数据，可以尝试识别出相同的偏移量区段(统计其规律，增或删触发)作预处理...
需要下载的补丁数据会更大一些； 块校验： fadler64bit + md5->64bit 的块校验（16字节）； (用fadler32bit的话12字节，略微节约下载大小，增大数据错误风险) 或者fadler128bit的块校验（16字节）; 优点:不需要依赖另外的md5库；缺点：速度比fadler64bit略慢，hash冲突没有经过考验（降低数据错误风险，可以考虑储存整个文件的另外校验值来兜底，但速度会更慢一点）； 压缩支持： 支持下载分块压缩的块数据
当前用roll hash的匹配方案实现了流式diff，速度ok；但输出大小没有尝试优化，可以选择放弃一些速度。 可能的方向： 1. 选择更多个可能的匹配位置，当前的实现只测试了可能最长的2个hash值位置； 2. 得到的cover线可以尝试向2边延长；3. 优先特殊匹配最前和最后位置优化速度 4. 可能考虑link线的合并是否有效？ 5. 现在匹配时用的贪心算法，可以考虑优先处理更长的匹配位置？