Здравствуйте. Как эффективно сравнить содержимое 2 файлов? Файлы могут быть любого типа, и любого размера, даже очень большие (и сравнивать надо будет очень много файлов). 

С какой целью сравнение?
Какой должен быть результат?
При первом несоответствии, какая реакция?

Даты файлов разные - сравнивать или нет?
Имена, размеры, расположение ..., ...

В общем случае, если сравнивать содержимое каталогов - то стоит оргнизовывать многопоточное сравнение.
Поток 1 - сравнивает файл1 и файл2
Поток 2 - сравнивает файл3 и файл4
Поток 3 - сравнивает файл5 и файл6
... и т.д.
Количество потоков не стоит делать много большим количества ядер.
В 2- 4 раза, подбирать эксперементально.
Операции ввода-вывода медленные, поэтому чтобы процессор не простаивал, не ждал когда прочтется очередная порция, пусть сранивает другую пару. Суммарно программа работать будет быстрее, чем однопоточная.

сравнение с целью найти все группы одинаковых. есть коллекция, каждый элемент которой - размер файла и путь к нему. коллекция сортированная по размеру. теперь я беру элементы, размер которых одинаковый, и надо по пути найти файлы, и сравнить содержимое -  ни название, ни атрибуты и т.д. на сравнение не влияют, только содержимое. и как именно сравнивать? файлы большие могут быть, в массив байтов не кинешь.

И не надо. Читаем оба файла побайтово и сравниваем. На первом несовпадении завершаем процесс и считаем, что файлы разные. Хранить при этом ничего не надо.

то есть одинаковых может быть много больше 2ух.

1. Тогда добавить вычисление какого-нить хэшкода во время сравнения.
Так как сравнение может прерваться раньше чем будет достигнут конец файла, то запоминаем для какого размера вычислен хэш.

И когда беремся сравнивать с следующим кадидатом, который уже тоже имеет такой список пар хэш-длина, продумываем довычисление хэша, и сравниваем хэши.
И только когда одинаковы, начинаем сравнивать как обычно, побайтно.

2. Можно еще поэскперементировать с таким алгоритмом:
Разбиваем файл на участки Nго размера (возможно зависящиае от его размера, скажем размер / 100)
Случайным образом выбираем участки для сравнения и сравниваем вычисляя хэши. Эту информацию запоминаем.
Это в первый раз.

Во второй, вначале сравниваем хэши участков, и продолжаем такое сравнение, если все оказались одинаковы, а еще есть необследованные участки.

При втором алгоритме вероятность коллизии хэша на глаз меньше, а быстродействие - выше(для работы с локальными дисками. При работе по сети может даже быть хуже чем у 1го, надо пробовать). Но кода писать придется больше 

1+2
Сраниваем всегда сначала, но храним хэши на кусочки файла, а не на всю часть до появления расхождения.

Хэши избавляют от сравнения разных файлов.
Одинаковые - придется сравнивать.
Или, использовать одновременно несколько разных алгоритмов вычисления хэша.
Тогда считать вероятность коллизии для всех видов хэша - невероятной.

И разумеется, все это - тем более делать многопоточным.

P.S.
А если не изобретать, то выковырять из торрент алгоритмов.

Это сообщение отредактировал(а) Skynin - 24.9.2011, 09:15

спасибо! а можно кусок кода, хотя бы для примера... ?

Вот тут чек-суммы достают http://stackoverflow.com/questions/304268/...es-md5-checksum

Добавлено через 1 минуту и 42 секунды
P.S. коллизией в хэш-суммах я бы пренебрег.