Другие ответы хороши - либо хэширование (если вы сравниваете файл с несколькими кандидатами), либо побайтовое сравнение (если сравниваете два отдельных файла).
Вот пара дополнительных мыслей:
Сначала проверьте размеры файлов - если они разные, не тратьте время на сравнение байтов. Это быстро проверить.
Во-вторых, попробуйте выполнить поиск в конце или середине файла, используя метод бинарной нарезки.
Например, предположим, у вас есть такой файл:
ABCDEFGHIJKLMNOP
Тогда это модифицируется так:
ABCDEF11GHIJKLMN
Если размер файла останется прежним, а содержимое будет вставлено, остальные байты будут "выбиты". Таким образом, бинарный подход может решить эту проблему с меньшим количеством операций чтения (например, при поиске и чтении байтов от SIZE / 2-10 до SIZE / 2 + 10 из обоих файлов и их сравнении).
Вы можете попытаться объединить приемы. Если вы сделаете это на достаточно хорошем образце данных, с которыми вы работаете, вы можете найти его для всех различных файлов, которые вы сравниваете (пример):
- 80% было найдено, потому что размер файла был разным (10 мс на файл)
- 10% были найдены из-за двоичной обработки (50 мс на файл)
- 10% были найдены благодаря линейному сравнению байтов (2000 мс на файл)
Делать бинарную нарезку по всему файлу было бы не очень разумно, так как я ожидаю, что жесткий диск будет быстрее, если выполнять линейное чтение, а не искать случайные места. Но если вы проверяете SIZE / 2, затем SIZE / 4 + SIZE / 4x3, а затем SIZE / 8, скажем, для 5 итераций, вы можете найти большинство различий без необходимости выполнять байтовое сравнение.
Просто несколько идей.
Кроме того, вместо чтения с начала файла, возможно, попробуйте прочитать с конца файла назад. Опять же, вы можете обменивать время поиска на вероятность, но в сценарии «вставка», предполагая, что в файл внесено изменение наполовину, вы, вероятно, найдете это быстрее, начиная с конца, чем с начала.