Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Sucherg.
Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Sucherg.
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?
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?
-
- Site Admin
- Posts: 4076
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
Wieviele Gruppen und Duplikate befinden sich in dem Suchergebnis?
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
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 ~247MBAdministrator wrote:Wieviele Gruppen und Duplikate befinden sich in dem Suchergebnis?
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.
-
- Site Admin
- Posts: 4076
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
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.
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.
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
Administrator wrote: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
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.Administrator wrote: 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.
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
-
- Site Admin
- Posts: 4076
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
Das kann Ihnen nur der Hersteller beantworten.Ist das (Grid) als array oder als verkettete Liste implementiert?
Da man die Nodes im TreeGrid per Index anspricht und nicht per Key gehe ich mal davon aus dass ein Array verwendet wird.
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
Ist der Zugriff auf das erste und das letzte Element gleich schnell, wenn man mit Index darauf zugreift?Administrator wrote:Das kann Ihnen nur der Hersteller beantworten.Ist das (Grid) als array oder als verkettete Liste implementiert?
Da man die Nodes im TreeGrid per Index anspricht und nicht per Key gehe ich mal davon aus dass ein Array verwendet wird.
Gibt es next() und prevous() Zugriffsfunktionalität?
-
- Site Admin
- Posts: 4076
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
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
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
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
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 wrote: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
-
- Site Admin
- Posts: 4076
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
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.
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.
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
Super! Ich bin neugierig: Was ist der Trick?Administrator wrote: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.
-
- Site Admin
- Posts: 4076
- Joined: 04 Oct 2004, 18:38
- Location: Thailand
- Contact:
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
Zugriff auf die Nodes per Index anstatt die Nutzung der internen Nodes-Collection.
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Such
Ich habe den alten Test ausgraben können.Administrator wrote: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.
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
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Sucherg.
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.
Re: Langsam:"Bitte warten, überprüfe+entf. Dat. aus dem Sucherg.
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
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