Zitat:
Pro "preprocessed line" wird ein 48-Byte großes Objekt erzeugt, und außerdem noch eine sortierte Liste ohne Duplikate in die alle Zeilen eingefügt werden und über die verkettete Listen erstellt werden
Bei mir sind das 38-58 Byte, ich habe das mit einem Pointer-Array gemacht (18 Byte) und einer sortierten Liste die das Pointer-Array indiziert (20 Byte). Dann kommt noch eine nicht näher definierbare sortierte Hashliste dazu, die wiederum die Startposition eines Hashblocks indiziert (auch 20 Byte, Anzahl der Einträge ist abhängig von der Anzahl der unterscheidlichen Hashes).
Zitat:
Und pro gefundenes Duplikat werden dann noch mal 1-2 TDuplicateSource Instanzen erzeugt (ebenfalls 48 Bytes groß) und eventuell auch noch eine TDuplicate Instanz (24 Bytes groß).
Ich lege die Duplikate in Paaren ab (2 x (24 byte + String(DateiName)).
Zitat:
Noch nicht berücksichtigt sind dabei diverse Listen die die Instanz-Zeiger enthalten und natürlich auch nicht die Strings (sowohl Original code als auch preprocessed code)...
Den Sourcecode und den preprocesseden Code werfe ich nach dem Einlesen der Files weg. Wenn ich den anzeigen muss, mache ich das durch erneuten Zugriff auf die Dateien.
Zitat:
Schafft es dein Programm diese Datenmengen zu bewältigen?
In der Version die ich jetzt gerade am Testen bin, ja. Vorher gab es auch EOutOfMemory. Dieser Test ist aber auch wirklich schon hart an der Grenze: Er umfasst die komplette
Program files\Borland Struktur, mit D7, D2006 und allen möglichen Fremdkomponenten drin. Aber es dauert dann auch ziemlich lange (47 Mrd. Vergleiche):
Code:
Files Zeilen Duplikate Vergleiche Dauer sek. Minuten Vergleiche/Sek.
5.260 4.956.663 39167 47.218.981.168 6803,02 113,38 6.940.885,25
Wie berechnest Du eigentlich die Laufzeit? Ich habe den Eindruck, es ist nur die Analyse Zeit. Bei mir fängt die Zählung an, sobald der User "Start" gedrückt hat.