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