我正在使用 bsdiff.exe 构建软件补丁并将其与 bspatch.exe 一起应用，到目前为止，对于小于 120MB 的文件没有任何问题。我拥有的一个二进制文件以前是 21MB，现在是 77MB，而且 bsdiff 似乎无限期地挂在上面。
根据文档，“bsdiff 非常消耗内存。它需要 max(17*n,9*n+m)+O(1) 字节的内存，其中 n 是旧文件的大小，m 是大小的新文件。” 这解释了大文件的问题，但是当增量较大时，问题似乎发生了。
有没有人有这方面的信息？任何事情都会有帮助，谢谢！
在尝试处理仅包含 2MB DSP 可执行代码的文件时，我还遇到了 bsdiff 崩溃的问题。
经过一些调试后，我确定问题出在 qsufsort 函数中，该函数用于基于“旧”文件创建后缀数组。qsufsort 调用一个名为 split 的函数，该函数递归地调用自身。在崩溃的情况下，递归调用发生了很多次，以至于程序耗尽了堆栈空间并引发了异常。
正如该线程所建议的那样： http ://bugs.debian.org/cgi-bin/bugreport.cgi?bug=409664 解决方案是用不同的解决方案替换 qsufsort 以生成后缀数组。后缀数组的维基百科条目引用 SA-IS，所以我从这里下载了源代码： https ://sites.google.com/site/yuta256/sais
然后，我将 bsdiff.c 与 sais.c 和 sais.h 一起重建，并将对 qsufsort 的调用替换为：
I[0] = 旧尺寸；sais(old, I+1, oldsize);
现在 bsdiff 每次都有效，而且速度也更快！
尝试此处列出的其他二进制差异程序之一：
https://stackoverflow.com/questions/688504/binary-diff-tool-for-very-large-files
这两个文件之间的差异需要的内存超出了表示这两个文件所需的内存。因此，处理两个具有许多差异的二进制文件将需要比两个相同文件更多的内存。
较小的文件有问题，因为软件中存在错误。Colin Percival，写它的人已经承认了这个错误，并说他没有时间修复它。