Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Sucherg.

[Anselm]

AllDup v4.08

nach einem großen Lauf warte ich auf "Bitte warten, überprüfe+entferne Dateien aus dem Suchergebnis".
Der Fortschrittsbalken steht auf 40% und geht langsam voran". Diese "überprüfe Aktion" läuft jetzt seit über über 1 Stunde. Wahrscheinlich eher 2. 12%CPU be 8 Kernen. Keine Festplattenaktivität, keine Netzaktivität und auch sonst nichts zu erkennen. Ich bin unschlüssig, ist das der Algorithmus? Oder ist der Speicher der 32Bit Applikation am Anschlag und das Prorgamm ist mit Speicherverwaltung beschäftigt?

[Administrator]

Wieviele Gruppen und Duplikate befinden sich in dem Suchergebnis?

[Anselm]

Wieviele Gruppen und Duplikate befinden sich in dem Suchergebnis?

163.061 Gruppen, 382.281 Dateien. Task Manager: 1.826.108K Arbeitssatz (Speicher), 2.031.264K Max. Arbeitssatz (Speicher). Speichen des Ergebnisses 1 Stunde 20 Minuten. Größe der asr4a Datei ~247MB

Ergebnis neu laden: 58 Minuten. 742.244K Arbeitzsatz (Speicher). Ich habe mir das Ganze mal während des Ladevograngs mit dem Process Monitor von SysInternals angsehen (Process Monitor
https://technet.microsoft.com/de-de/sys ... nitor.aspx).

Dort kann ich sehen, dass in ganz kleine Häppchen gelesen wird 1Byte, 2Byte, 8Byte, 80-90 Byte. Das ist in anderen Programmiersprachen ein Hinweis darauf, dass kein BufferReader Wrapper verwendet wird (bzw. BufferedWriter Wrapper), der den Lese- und Schreibvorgang um Faktor 10 Beschleunigen kann.

Beim Export in CSV zeigt mir der ProcessMonitor um die 400 Byte große Häppchen an (wahrscheinlich imer eine Zeile). Das Ergebnis ist in unter 4 Minuten geschrieben, 162MB.

Eine Schreibsequenz für die asr4a Datei sieht Beispielsweise zur Zeit so aus (Länge der Häppchen in Bytes): 1,4,4,6,4,2,4,1,2,1,4,4,5,4,2,4,1,4,4,4,4,2,4,1,1,1,2,4,1,62


"Alle Gruppen entfernen, bei welchen die Duplikate nicht im selben Quellordner vorhanden sind" ist auch nach dem Neuladen langsam (jetzt kann der Speicher nicht die Ursache sein), ich habe einen winzig kleinen Fortschritts-Balken nach 5 Minuten warten.

[Administrator]

Hier stoßen Sie an die Grenzen.
Bei der Menge an Gruppen/Dateien wird jede Funktion in Bezug auf das Suchergebnis extrem langsam.
Das lässt sich leider bei Verwendung einer Liste mit Baumstruktur anstatt einer flachen Liste nicht vermeiden.
Eine flache Liste wäre schneller, aber unübersichtlicher, da es keine Gruppen mehr gäbe, die man auf- oder zuklappen könnte...
Ich hatte dies mal vor kurzem getestet:
Zeitaufwand der kplt. Suche bei einer flache Liste: 25sek
Zeitaufwand der kplt. Suche mit Baumstruktur: >3Min!
Der Zeitgewinn ist schon enorm...

Auf das Speichern kann man leider keinen Einfluß nehmen, da wir die bereitgestellten Speicherfunktionen des Herstellers vom Grid verwenden.
Alternativ müsste man die komplette Speicher/Lade-Funktion selbst programmieren.
Wird wahrscheinlich schneller sein...ich notiere dies mal auf der ToDo-Liste.

[Anselm]

Hier stoßen Sie an die Grenzen.
Bei der Menge an Gruppen/Dateien wird jede Funktion in Bezug auf das Suchergebnis extrem langsam.
Das lässt sich leider bei Verwendung einer Liste mit Baumstruktur anstatt einer flachen Liste nicht vermeiden.
Eine flache Liste wäre schneller, aber unübersichtlicher, da es keine Gruppen mehr gäbe, die man auf- oder zuklappen könnte

Auf das Speichern kann man leider keinen Einfluß nehmen, da wir die bereitgestellten Speicherfunktionen des Herstellers vom Grid verwenden.
Alternativ müsste man die komplette Speicher/Lade-Funktion selbst programmieren.
Wird wahrscheinlich schneller sein...ich notiere dies mal auf der ToDo-Liste.

Ist das (Grid) als array oder als verkettete Liste implementiert? Für mich sieht es so aus, als wenn die Liste immer wieder von vorne durch gegangen wird, um eine Operation auszuführen.
Ich habe noch ein paar Test gemacht. Das Speichern wird langsamer, je mehr Daten geschrieben werden.

Code: Select all

Test, bei dem 115MB geschrieben werden. Gruppen: 67251; Dateien 163731

Spalten Beschreibung
#1=erwartetes Ende (Zeit)
#2= % der verarbeiteten/geschriebenen Daten
#3=Anzahl der Daten, die bisher geschrieben wurden
#4=Gesamtanzahl der zu schreibenden Daten
#5=bisher gebrauchte Zeit
#6=Durchsatz Daten pro Sekunde (#3 / #5 in Sekunden)

Code: Select all

#1			#2	#3		#4		#5							#6
00:01:21	10	06748	67521	00:00:09					749,78
00:02:03	20	13278	67521	00:00:30					442,60
00:02:40	30	20106	67521	00:01:08					295,68
00:03:06	40	26871	67521	00:02:03					218,47
00:03:13	50	33563	67521	00:03:11					175,73
00:03:05	60	40268	67521	00:04:33					147,51
00:02:42	70	46986	67521	00:06:10					126,99
00:02:01	80	54333	67521	00:08:18					109,11
00:01:12	90	60558	67521	00:10:25					96,90

Wie man sehen kann, nimmt der Durchsatz stark ab, je mehr Daten geschrieben wurden. Das liegt sicher nicht daran, dass die Ausgabe nicht gebuffered ist. Es kommt einem so vor, als würde das Grid die Liste immer wieder von Vorne durcharbeiten, um das zu speichernde Element zu finden.

[Administrator]

Ist das (Grid) als array oder als verkettete Liste implementiert?

Das kann Ihnen nur der Hersteller beantworten.
Da man die Nodes im TreeGrid per Index anspricht und nicht per Key gehe ich mal davon aus dass ein Array verwendet wird.

[Anselm]

Ist das (Grid) als array oder als verkettete Liste implementiert?

Das kann Ihnen nur der Hersteller beantworten.
Da man die Nodes im TreeGrid per Index anspricht und nicht per Key gehe ich mal davon aus dass ein Array verwendet wird.

Ist der Zugriff auf das erste und das letzte Element gleich schnell, wenn man mit Index darauf zugreift?
Gibt es next() und prevous() Zugriffsfunktionalität?

[Administrator]

Diese Tests haben sich erledigt.
Ich teste momentan noch einen TreeGird von einem anderen Hersteller, welcher bei den bisherigen Tests extrem performanter ist!
Da das aktuelle Suchergebnis komplett auf die Funktionen des jetzigen TreeGrids programmiert wurde, wird eine solche Umstellung allerdings noch eine ganze Weile dauern...

Hier noch ein paar Daten zu dem Test:

Suchmethode: Dateiname
Quelle: C:\Windows mit 110.342 Dateien
Duplikate: 76.175
Gruppen: 18.484

AllDup 4.0.12 benötigt hierfür 2m20s zum Erstellen des Suchergebnisses und mit dem neuen Treegrid sind es nur noch 31s bei dieser Datenmenge!

Bei diesem positiven Testergebnis ist die Motivation für eine Umstellung natürlich hoch.
Das Speichern und laden wird dann zukünftig dementsprechend auch schneller vonstattengehen.
Genauso wie das Auf- und Zuklappen der Gruppen.
Ich hoffe innig das sich bei weiteren Tests nicht irgendwo noch irgendwelche Nachteile ergeben.
Es wäre auch zu schön endlich die eierlegende Wollmilchsau gefunden zu haben

[Anselm]

Diese Tests haben sich erledigt.
Ich teste momentan noch einen TreeGird von einem anderen Hersteller, welcher bei den bisherigen Tests extrem performanter ist!
Da das aktuelle Suchergebnis komplett auf die Funktionen des jetzigen TreeGrids programmiert wurde, wird eine solche Umstellung allerdings noch eine ganze Weile dauern...

Hier noch ein paar Daten zu dem Test:

Suchmethode: Dateiname
Quelle: C:\Windows mit 110.342 Dateien
Duplikate: 76.175
Gruppen: 18.484

AllDup 4.0.12 benötigt hierfür 2m20s zum Erstellen des Suchergebnisses und mit dem neuen Treegrid sind es nur noch 31s bei dieser Datenmenge!

Bei diesem positiven Testergebnis ist die Motivation für eine Umstellung natürlich hoch.
Das Speichern und laden wird dann zukünftig dementsprechend auch schneller vonstattengehen.
Genauso wie das Auf- und Zuklappen der Gruppen.
Ich hoffe innig das sich bei weiteren Tests nicht irgendwo noch irgendwelche Nachteile ergeben.
Es wäre auch zu schön endlich die eierlegende Wollmilchsau gefunden zu haben

Das klingt ja super vielversprechend. Da geht ja für die Zeit des Erstellens schon ziemlich viel Zeit durch das Grid "verloren". Das hätte ich so extrem nicht vermutet.

[Administrator]

Ich konnte in der Zwischenzeit die Speicherfunktion des aktuellen Grids optimieren.
Bei einem Test wurde die benötigte Zeit beim Speichern von 11605 Gruppen und 58144 Dateien von 1 Minute auf 10 Sekunden reduziert!
Zusätzlich wurden noch verschiedenen Funktionen zum Auf- und Zuklappen oder Entfernen von Gruppen optimiert welche jetzt auch schneller durchgeführt werden.

[Anselm]

Ich konnte in der Zwischenzeit die Speicherfunktion des aktuellen Grids optimieren.
Bei einem Test wurde die benötigte Zeit beim Speichern von 11605 Gruppen und 58144 Dateien von 1 Minute auf 10 Sekunden reduziert!
Zusätzlich wurden noch verschiedenen Funktionen zum Auf- und Zuklappen oder Entfernen von Gruppen optimiert welche jetzt auch schneller durchgeführt werden.

Super! Ich bin neugierig: Was ist der Trick?

[Administrator]

Zugriff auf die Nodes per Index anstatt die Nutzung der internen Nodes-Collection.

[Anselm]

Ich konnte in der Zwischenzeit die Speicherfunktion des aktuellen Grids optimieren.
Bei einem Test wurde die benötigte Zeit beim Speichern von 11605 Gruppen und 58144 Dateien von 1 Minute auf 10 Sekunden reduziert!
Zusätzlich wurden noch verschiedenen Funktionen zum Auf- und Zuklappen oder Entfernen von Gruppen optimiert welche jetzt auch schneller durchgeführt werden.

Ich habe den alten Test ausgraben können.

Speichern wegen der Optimierung in AllDup 4.0.14 in 1 Minute 8 Sekunden (Super, Danke!)
Laden etwas über 10 Minuten.
Selektieren von Dateien: gut
Ausklappen von Gruppen: Langsam.
Zusammenklappen von Gruppen: Schnell

[xmas]

Es ist 2024 und ich frage mich, ob sich an dieser Stelle noch etwas entwickelt hat oder nicht. Aus meiner Sicht ist es immer noch unwahrscheinlich langsam. Es sind nun bald zehn Jahre her, wo diese Frage gestellt wurde, und die Datenmengen und Werte sind über die Zeit nicht weniger geworden, die man versucht damit zu ordnen. Bei mir sind es nur 200.000 Gruppen und alleine das Laden wird geschätzt auf 25 Minuten aber am Ende dauert es Circa 2 Stunden. Das Häckchen setzen. Bei einzelnen Dateien dauert pro Datei 40-60 Sekunden. Automatische Auswahl oder abwahlen dauern um die 5 Stunden. Gibt es irgendetwas was ich tun kann? an Prozessor und Speicher kann es nicht liegen, da die Prozessorlast nie 12 % übersteigt und vom Speicher/RAM nie mehr als ein Zehntel genutzt wird. desweiteren sind alle Daten auf SSDs.

[Tesla]

nur 2 Stunden? - Du Glücklicher!

Das Problem ist einfach, dass der Code von AllDup leider nicht multithreadfähig kompiliert ist.
Gerade Arrays von einzelnen Aktionen könnte man wunderbar parallelisieren.
Ich hoffe wirklich, dass das in der nächsten Version kommt.

Mein AllDup läuft schon eine Woche durch.
hier ein Auszug aus dem Logfile mit der letzten Aktion fast 13 Stunden:
08.09.2024 12:41:20 - Die Anzahl der Dateien wird ermittelt...
08.09.2024 12:44:11 - Dateianzahl: 813.309
08.09.2024 12:44:12 - Durchsuche: F:\2022-09-29 iPad
08.09.2024 12:44:31 - Dateien ausgeschlossen: 273 (259,76 GB)
08.09.2024 12:44:31 - Durchsuche: F:\Target 1
08.09.2024 12:45:06 - Dateien ausgeschlossen: 174 (51,60 GB)
08.09.2024 12:45:06 - Durchsuche: F:\Target 2
08.09.2024 16:47:12 - Dateien ausgeschlossen: 2.474 (1.099,60 GB)
08.09.2024 16:47:12 - Durchsuche: F:\System Volume Information
08.09.2024 16:47:12 - Durchsuche: F:\Tenorshare
08.09.2024 16:47:12 - Durchsuche: F:\TS_UltData_Save_Path
08.09.2024 17:36:28 - Dateien ausgeschlossen: 3.404 (446,30 GB)
08.09.2024 17:36:28 - Durchsuche: H:\Source
09.09.2024 01:38:24 - Dateien ausgeschlossen: 1.967 (810,60 GB)
09.09.2024 01:38:27 - 3.880 Duplikate mit insgesamt 10,04 GB in 'F:\2022-09-29 iPad' gefunden
09.09.2024 01:38:27 - 516 Duplikate mit insgesamt 1,13 GB in 'F:\Target 1' gefunden
09.09.2024 01:38:27 - 329.110 Duplikate mit insgesamt 480,09 GB in 'F:\Target 2' gefunden
09.09.2024 01:38:27 - 20.420 Duplikate mit insgesamt 172,11 GB in 'F:\TS_UltData_Save_Path' gefunden
09.09.2024 01:38:27 - 284.049 Duplikate mit insgesamt 469,65 GB in 'H:\Source' gefunden
09.09.2024 01:39:28 - Überprüfte Dateien: 813.309
09.09.2024 01:39:28 - Gruppen: 265.673
09.09.2024 01:39:28 - Dateivergleiche: 10.243.406
09.09.2024 01:39:28 - Prüfsummen erstellt: 732.908
09.09.2024 01:39:28 - Datenbank-Prüfsummen verwendet: 8.870
09.09.2024 01:39:28 - Datenbank-Prüfsummen gespeichert: 732.316
09.09.2024 01:39:28 - Datenbank-Prüfsummen aktualisiert: 592
09.09.2024 01:39:28 - Duplikate: 637.975 (78%) (1,11 TB)
09.09.2024 01:39:28 - Zeitaufwand: 12:57:07