nb pisze:

> #time crc32 K* # szybkośc obliczenia crc
> bb2b61ee K2.avi
> bb2b61ee Kolja-DVD.avi
> real 0m42.831s
> user 0m7.646s
> sys 0m7.237s
>
> #time fdupes . # szybkość działania fdupes
> ./Kolja-DVD.avi
> ./K2.avi
> real 5m33.525s
> user 4m36.092s
> sys 0m14.206s
>
> Widać, że patent z crc jest około 8 razy szybszy.
> Nawet md5 (wykluczający przypadkową zbieżność crc)
> będzie pięć razy szybszy.
>

No ten przykład świadczy na niekorzyść fdupes. Miałes 2 jednakowe pliki
więc żeby stwierdzić, że są jednakowe musiały być przeczytane w całości
niezaleznie czy bezpośrednio porównane, czy liczona jakaś suma. Mnie się
wydaje, że liczenie sum powinno być wolniejsze, bo to dodatkowa zbędna
operacja.
Wielu chce liczyć te sumy, bo potrzeba te pliki (czy sumy) posortować
przed porównaniem, nie do przyjęcia jest porównywanie każdy z każdym.
Ja osobiscie zastosował bym nastepujący algorytm (zakładam, że już
odrzuciliśmy ze względu na długość):
- czytamy po 10..100 początkowych bajtów plików, zapisujemy do tablicy
- sortujemy (sort)
- szukamy duplikatów (uniq)
- dla znalezionych duplikatów porównujemy całość, a jak mamy ich
bardzo dużo to powtarzamy procedurę dla większej ilosci bajtów
poczatkowych.

Dlaczego tak?
Przede wszystkim powtarzających się plików będzie raczej niedużo, jest
to jakaś patologia z którą walczymy. Czyli plików różnych może być 99%,
a żeby stwierdzić różność nie trzeba czytać całości. Po drugie zapewne
nawet dla bardzo długich plików różnica będzie już gdzieś na początku.
Plików jednakowej długosci może być całkiem sporo biorąc pod uwagę, ze
mogą to być zdjęcia w RAW.