Falls du nur zwei Dateien -> Datei A und Datei B vergleichen möchtest, dann benutzt du einen binären Direktvergleich.
Falls du aber zb. 16 Dateien mit jeweils 1 Mb alle untereinander vergleichen möchtest so benötigst du mit deiner Methode
16 * 16 komplette binäre Vergleiche die 16 * 16 * 1Mb = 256Mb Daten einlesen.
Mit der Hash Methode werden erstmal
16 * 1Mb = 16 Mb Daten eingelesen und ein Hash erzeugt, a 16 Bytes = 256 Bytes.
Dann werden diese 16 Hashs untereinander verglichen also 16 * 16 Vergleiche a 16 Bytes = 8192 Bytes Daten.
Da aber nun diese 16 Hash's schon bei ihrer Erzeugung in einer Sortierten Listen gespeichert werden, benötigt man effektiv nur durchschnittlich Ln2(16) * 16 = 64 Vergleiche mit ergo 1024 Bytes.
Insgesamt also
16 MByte bei 16 Dateien.
Deine Methode beackert 256 Mb Daten.
Meine Methode beackert 16 Mb Daten und die Hashvergleiche sind vernachlässigenbar.
Da der Hash 128 Bit groß ist, ist die Wahrscheinlichkeit das du 2 Dateien findest die gleiche Hashs bilden aber denoch unterschiedlich sind 1/2^64 groß. Du müsstest also im Durchschnitt 18446744073709551616 Dateien hashen um dann einmal gezwungen zu sein zwei Dateien wirklich binär vergleichen zu müssen.
Wenn also meine Methode mit 50% Wahrscheinlichkeit gezwungen sein soll bei einem Set aus 1 Mb großen Dateien einen tatsächlichen binären Vergleich durchzuführen, heist dies das insgesamt 16384 Yotabytes an Dateien gehasht werden um dann nochmals 2 Mb an Daten binär gegeneinadner vergleichen zu müssen.
16384 Yotabytes = 18446744073709551616 Megabytes.
Ich wüsste nicht das die Menschheit im gesammten 16384 Yotabytes an 1 Mb großen Dateien überhaupt speichern könnte.
Man kann also technisch fast mit 100 Prozent Sicherheit ausschließen das wenn zwei Dateien einen gleichen Hash erzeugen diese denoch unterschiedlich sind.
Mit deiner Methode würdest du bei gleicher Anzahl Dateien dann
302231454903657293676544 Yotabytes = 340282366920938463463374607431768211456 Megabytes vergleichen müssen.
Also schon ab minimal 3 Dateivergleichen, also Datei A wird mit Datei B und C verglichen wird meine Methode quadratisch schneller sein.
Nicht zu vernachlässigen ist der Punkt wie das Betriebsystem arbeiten muß wenn es im Vergleich entweder nur 1 Datei laden muß, einen Hash errechnet und danach eine zweite Datei laden mußund einen Hash errechnet, oder eben sofort zwei Dateien laden muß. Im ersteren Falle können die internen Caches der Festplatte/CPU etc. pp. mit einer Datei alleine ausgelastet werden, im zweiten Falle müssen diese Caches 2 Dateien speichern. Desweiteren ist di Wahscheinlichkeit sehr groß das eine Datei sequientiell auf der Festplatte Sektor für Sektor gespeichert wurde. Lädt man nur eine Datei sequientiell in den Speicher so werden die Kopfbewegungen der HD also optimaler sein, als wenn man abwechselnd immer Sektorweise auf 2 Dateien repositionieren muß.
Ach nochwas: vergiß den Vorschlag von St. Pauli und nimm einfach meine
Unit. MD4 ist ca. doppelt so schnell wie MD5 und die geringeren Kollisionen des MD5's im Vergleich zum MD4 können, wie mit obigen Zahlen gezeigt, absolut vernachlässigt werden.
Wir benötigen hier keine perfekte kryptographische Sicherheit die MD5 rechtfertigen könnten, sondern nur eine sehr schnelle Methode um eine ausreichend gute Prüfsumme erzeugen zu können.
[edit]
Schaut man sich MD5File genauer an so erkennt man das dort mit Memory Mapped Files gearbeitet wird. In meiner
Unit habe ich dies eben absichtloch nicht gemacht, und das aus gutem Grunde. Memory Mapped Files mappen wie in MD5File() demonstriert das komplette File in den Speicher, das hat hohe Priorität. Der dahinterliegende Mechanismus ist sehr kompliziert. Das führt dazu das bei großen Dateien die MMFs das
OS zwingen Hauptspeicherresourcen anderer Anwendungen ins Swapfile auzulagern. Fazit: MMFs sind nicht dafür konstruiert wurden Dateien schnell zu laden, eine gebufferte Methode ist immer schneller.
[/edit]
Gruß Hagen