[GERMAN]Starke Performanceprobleme

[ChristopherFoto]

Seit einigen Tagen habe ich starke Performanceprobleme mit IMatch 2018.10.6.
Ich starte IMatch und schriebe im Kategoriefilter z.B. Baier, hier werden dann in den Kategorien die Kategorie "Baiersbron" gefunden mit 14 Bildern.
Diese werde aber erst nach etwa 2 Minuten angezeigt. Dies ist der AUszug aus dem LOG.

Code Select Expand

10.10 22:28:11+  297 [2AA4] 50  M>                < 15 [297ms] CIMDXCacheManagerLoaderDelegate::InnerLoad
10.10 22:30:05+114547 [1BE8] 10  M>                > 15 CIMEngineUpdateQueue::Enable  'v:\develop\imatch5\src\imengine\imengineupdatequeue.cpp(2209)'

Das Komplette Debug-Log habe ich als ZIP angehängt.

Zum System: Windows 10 1803, I7 16 GB RAM, SSD1 Betriebssystem (Laufwerk c:), SSD2 IMAtch Datenbank (Laufwerk e:), die Bilder ligen auf einem Hardware-Raid 1 mit 4TB (Laufwerk d:)

Wichtiger Hinweis: Die Datenbank liegt Physikalisch im Laufwerk E: hier gibt es MKLINK-Verbindung, dies hat zu keinem Zeitpunkt ein Problem dargestellt und wird schon mehrere Jahre verwendet.

Code Select Expand

Datenträger in Laufwerk C: ist Windows 10
Volumeseriennummer: 80BC-99E9

Verzeichnis von c:\ProgramData\photools.com\imatch6

10.10.2018  22:50    <DIR>          .
10.10.2018  22:50    <DIR>          ..
03.10.2018  21:11    <DIR>          annotations
10.10.2018  22:11    <DIR>          browser
03.10.2018  21:12    <JUNCTION>     config [e:\IMatch2017\config]
03.10.2018  21:11    <DIR>          data
03.10.2018  21:12    <JUNCTION>     Datenbank [e:\IMatch2017\Datenbank]
21.01.2018  20:22    <DIR>          dictionaries
03.10.2018  21:11    <DIR>          IMWS
03.10.2018  21:11    <DIR>          plugins
03.10.2018  21:11    <DIR>          presets
03.10.2018  21:12    <JUNCTION>     previewcache [e:\IMatch2017\previewcache]
03.10.2018  21:11    <DIR>          printing
03.10.2018  21:11    <DIR>          resources
03.10.2018  21:12    <JUNCTION>     webroot [e:\IMatch2017\webroot]
               0 Datei(en),              0 Bytes
              15 Verzeichnis(se), 33.961.193.472 Bytes frei
 

In dem Metadaten 2 unter Dateiformate, wurde beim Dateiformat NEF alles auf "NEIN" gestellt und "Erzwinge XMP-Sidecar-Datei".
Auch diese Einstellungen verwende ich seit mehreren Jahren so.
Ein "Komprimieren und Optimieren" der Datenbank sowie eine "Datenbankanalyse" brachten keine Abhilfe.
Ebensowenig wie eine Reparatur-Installation.

Hat noch jemand eine Idee?

[Mario]

Seit einigen Tagen habe ich starke Performanceprobleme mit IMatch 2018.10.6.

Was hat sich geändert?
IMatch als Ausnahme im Virus-Checker definiert?
System mal neu gestartet?

[ChristopherFoto]

Hallo Mario,

Was hat sich geändert?

Adobe Lightroom, Bridge und Photoshop CC wurden installiert.

IMatch als Ausnahme im Virus-Checker definiert?

GData Antivirus komplett ausgeschaltet -> keine Abhilfe

System mal neu gestartet?

JA, ebenfalls ohne Erfolg

[Mario]

Das Log file zeigt nicht viel, nur einen Start von IMatch.
Das Laden einer 30K files Datebank dauerst bei Deinem System 7 Sekunden, was etwas zäh ist. Vor allem von einer SSD.
Das Hochfahren des UIs ist auch nicht wirklich flott.

Hattest Du andere Anwendungen laufen? Adobe-Produkte allozieren Unmengen an Speicher und können die CPU start auslasten.
Allerdings nutze ich immer Photoshop, Lr und Affinity Designer zeitgleich mit einer 150,000 Dateien IMatch DB ohne Probleme. Und lasse noch zwei Datenbankserver im Hintergrund laufen.

Wenn das Performance-Problem plötzlich auftrat ist die Ursache wohl eher nicht bei IMatch zu suchen.
Beende mal andere Anwendungen, HintergrundTasks, Setze IMatch in GData als Ausnahme und sehr wichtig auch das ganze DB-Verzeichnis als Ausnahme. Sowohl das physische Verzeichnis als auch den hard link! Ich nutze auch G-Data auf einem System und das macht normalerweise mit IMatch keine Probleme, sofern das Datenbankverzeichnis ausgenommen ist.

Vielleicht bremst auch das NAS die DB aus. IMatch muss oft prüfen, ob Dateien/Verzeichnisse online sind. Das Ergebnis wird lokal im Speicher gecached, dennoch habe ich NAS-Boxen gesehen, die 2 Sekunden für die Beantwortung der Frage "Existiert die Datei xyz" brauchen. Und wenn IMatch den Status eines ganzen Verzeichnisses anfragen muss...

Check mal das NAS und die Performance. NAS-Boxen lassen normalerweise immer SAMBA unter Linux laufen um ein Windows-Dateisystem zu simulieren. Das kann zäh sein.

[ChristopherFoto]

Das Log file zeigt nicht viel, nur einen Start von IMatch.
Das Laden einer 30K files Datebank dauerst bei Deinem System 7 Sekunden, was etwas zäh ist. Vor allem von einer SSD.
Das Hochfahren des UIs ist auch nicht wirklich flott.

Hattest Du andere Anwendungen laufen? Adobe-Produkte allozieren Unmengen an Speicher und können die CPU start auslasten.
Allerdings nutze ich immer Photoshop, Lr und Affinity Designer zeitgleich mit einer 150,000 Dateien IMatch DB ohne Probleme. Und lasse noch zwei Datenbankserver im Hintergrund laufen.

Nein, es lief nur IMatch, Firefox, The Bat! (eMail-Client), Eizo Monitortool, Teamviewer, das wars.
Keines der Adobe Produkte wurde gestartet

Wenn das Performance-Problem plötzlich auftrat ist die Ursache wohl eher nicht bei IMatch zu suchen.
Beende mal andere Anwendungen, HintergrundTasks, Setze IMatch in GData als Ausnahme und sehr wichtig auch das ganze DB-Verzeichnis als Ausnahme. Sowohl das physische Verzeichnis als auch den hard link! Ich nutze auch G-Data auf einem System und das macht normalerweise mit IMatch keine Probleme, sofern das Datenbankverzeichnis ausgenommen ist.

Habe alle Adobe-Processe beendet, GData ausgeschaltet (ist hier kein Problem, die Machine läuft hinter einer Fortigate Firewall).Ebenso diese Anwendungen beendet: Firefox, The Bat! (eMail-Client), Eizo Monitortool, Teamviewer.
IMatch beendet und neu gestartet, leider ohne Erfolg.

Vielleicht bremst auch das NAS die DB aus. IMatch muss oft prüfen, ob Dateien/Verzeichnisse online sind. Das Ergebnis wird lokal im Speicher gecached, dennoch habe ich NAS-Boxen gesehen, die 2 Sekunden für die Beantwortung der Frage "Existiert die Datei xyz" brauchen. Und wenn IMatch den Status eines ganzen Verzeichnisses anfragen muss...

Check mal das NAS und die Performance. NAS-Boxen lassen normalerweise immer SAMBA unter Linux laufen um ein Windows-Dateisystem zu simulieren. Das kann zäh sein.

Ich verwende kein NAS, das Raid hängt an einem Hardware-Raidcontroller direkt im PC.

Bei meinen Tests ist mir noch etwas aufgefallen:
Testzenario: Braunbär in Kategorie ausgewählt, gewartet bis diese alle angezeigt wurden.
IMatch beendet und neu gestartet, die Bilder in der Kategorie Braunbär werden sofort dargestellt.
Nun Suche über den Kategoriefilter "Baier", nun dauert es wieder die knapp 2 Minuten bis die Bilder angezeigt werden.
Nun wieder zurück zur Kategorie Braunbär.

IMatch geschlossen und neu gestartet, die Bilder in der Kategorie Braunbär werden sofort dargestellt.
Nun nicht über die Suche zur Kategorie "Baiersbron" sondern direkte Auswahl im Kategoriebaum.
Nun werden die Bilder ohne Verzögerung dargestellt.
Es muss also irgendwas mit der Suchfunktion zu tun haben.

[Mario]

Nun Suche über den Kategoriefilter "Baier", nun dauert es wieder die knapp 2 Minuten bis die Bilder angezeigt werden.

Bitte das Logfile im DEBUG mode (see log file) von diesem Test anhängen.

[ChristopherFoto]

Nun Suche über den Kategoriefilter "Baier", nun dauert es wieder die knapp 2 Minuten bis die Bilder angezeigt werden.

Bitte das Logfile im DEBUG mode (see log file) von diesem Test anhängen.

Hallo Mario,
hier die beiden Log-Files des Tests.
Gruß Christopher

[Mario]

Es wurden keine außergewöhnlich (> 5s) lang dauernden Events aufgezeichnet (außer den normalen wie DB öffnen/ruterfahren). Nichts was 2 Minuten gedauert hat.
Der Filter "Categories" im Categroy Panel filtert in < 10 ms und lädt das Dateifenster in ca. 0.2 bis wenigen Sekunden neu (je nach Anzahl der Dateien. Es sei denn Du filterst nach datengestützten Kategorien und die müssen erst noch aktualisiert werden.

Auf meinem System nach einer @Keywords Categroy filten: 20 ms für den Filter, Gesamteit bis zum kompleten Laden des Dateifensters: < 1 s (200 Treffer). DB mit 50K files.

Ich vermute eine externe Ursache für das Problem, kein IMatch Problem.

[ChristopherFoto]

Es wurden keine außergewöhnlich (> 5s) lang dauernden Events aufgezeichnet (außer den normalen wie DB öffnen/ruterfahren). Nichts was 2 Minuten gedauert hat.

In der LOG-Datei "IMATCH6_LOG_Kategoriesuche.TXT" ist die lange Wartezeit vorhanden

Code Select Expand

10.11 15:16:51+   78 [260C] 50  M>                < 15 [78ms] CIMDXCacheManagerLoaderDelegate::InnerLoad
10.11 15:19:07+135594 [1BB4] 10  M>                > 15 CIMEngineUpdateQueue::Enable  'v:\develop\imatch5\src\imengine\imengineupdatequeue.cpp(2209)'


[Mario]

Das ist keine Ausführunszeit sondern idle time (IMatch hat nichts getan zwischen diesen beiden Einträgen)

[ChristopherFoto]

Das ist keine Ausführunszeit sondern idle time (IMatch hat nichts getan zwischen diesen beiden Einträgen)

Das ist aber genau die Zeit, in der nichts passiert, also ich noch auf die Darstellung der Bilder warte.

[sinus]

Sorry, ich mache das nie, deshalb, Ihr redet schon von dieser Suche, siehe Attachement?

Ich habe das versucht bei mir, obwohl fast 260'000 Bilder und fast 17'000 Categorien funktioniert das sehr schnell.
Bei den Filtereinstellungen habe ich "Contains" eingestellt (beim Dreieck rechts neben dem Filter).

Oder meint Ihr was ganz anderes?

896 folders
258360 files
16747 categories

[ChristopherFoto]

Hallo,


ich spreche von dem oberen "search" Feld aus deinem Screenshot.


Gruß Christopher

[sinus]

Hallo,
ich spreche von dem oberen "search" Feld aus deinem Screenshot.
Gruß Christopher

Ah, danke.
Habe das grad probiert.
Wenn ich ein Wort eingebe, dann dauert das rund 1-3 Sekunden, dann sind die Bilder da.
Mal 5, mal 169, dann 77 oder grad zuletzt "Josef" mit 241 Bildern.

Hier kein Problem. Version ist 2018.10.6

[ChristopherFoto]

Hab nun neben IMatch auch noch den Task-Manager und den Ressourcenmonitor offen.
Im Leerlauf, also wenn IMatch nichts unternimmt, liegt die CPU-Auslastung von IMatch zwichen 0% und 0,2%, was ich als normal erachten würde.
Lasse ich IMatch über den Kategoriefilter suchen, steigt die CPU-Auslastung auf 13-14% an und zwar so lange, bis das Egebnis (Bilder) dargestellt  werden, danach geht die CPU-Auslastung von IMatch wieder auf 0% bis 0,2% zurück.
Dies habe ich in den Hintergrundaktivitäten konfiguriert, siehe Screenshot.

Das ist keine Ausführunszeit sondern idle time (IMatch hat nichts getan zwischen diesen beiden Einträgen)

Wenn dem so wäre, woher kommen dann die relativ hohe CPU-Auslastung von IMatch (13-14%) fürs nichts tun? Aus meiner Sicht beschäftigt sich IMatch irgendwie mit sich selbst, auch wenn dies bei anderen nicht der Fall ist.

[ChristopherFoto]

Ich habe nun folgendes ausprobiert.
Betriebssystem mit O&O Diskimage auf den Stand vom 14.09.2018 wiederhergestellt.
Diese enthielt IMatch 2018.8.8
Letztes Backup von IMatch vom 1.10.2018 ebenfalls IMatch 2018.8.8 wiederhergestellt.
Imatch gestartet.
Damit lies sich das Problem nicht mehr herstellen, die Suche im Kategorie-Filter ging ohne Probleme und nennenswerte Zeitverzögerung.
Update IMatch auf 2018.10.6.
Damit ist das Problem wieder vorhanden, es liegt also nicht am PC oder sonst irgendeiner komponente sondern eindeutig an IMatch 2018.10.6.
Was auch immer hier geschehen ist.

Es wurde zu keinem Zeitpunkt von mir ein Update der Datenbank veranlasst, beim Update von 8.8 auf 10.6 wurde evtl. durch die Installation ein Update durchgeführt, aber das musst du besser wissen als ich.

[Mario]

Die Suchfunktion im Kategoriebaum mittels der Properties (darum geht es ja?) ist eine eingebaute Funktion in der Oberflächenbibliothek eines Drittherstellers. Ich kann 8000 Kategorien in weniger als einer Sekunde durchsuchen. Plus die Ladezeit der Dateien der gefundenen Kategorie ins Dateifenster. Also 1.5 bis 2 Sekunden.

Die Suche muss aber alle Kategorien aufklappen und die Kindkategorien laden. Wenn Du data-driven categories hast die pending sind oder langsame formelbasierte Kategorien, kann das die Dinge verzögern. Davon sehe ich aber nichts im Log.

Es gab auch seit mehreren Monaten kein Update der Bibliothek. Daher auch keine Änderung an IMatch 2018.

Vielleicht liegt es an deinen Kategorien oder wie die Nodes aufgeklappt sind oder sonstwas. Klapp doch mal alle Kategorien auf und update alle data-driven categories vor der Suche.

Lade die Datenbank mal in Deinen Clousd-Space und sende mir einen Download-Link.  Es kann aber ein ein- oder zwei Wochen dauern, bis ich für so einen Analyse Zeit finde.

[ChristopherFoto]

Hallo Mario,


hab dir eine Mail geschrieben.


Gruß Christopher

[ChristopherFoto]

Ich habe ja direkt von 8.8 auf 10.6 eine Update ausgeführt.
Auch habe ich die Versionen 10.4 auf dem Upgradepfad fehlt mir aber die Version 10.2
Besteht die Möglichkiet mir diese noch mal zur Verfügung zu stellen, so das ich die Version 8.8 über 10.2, 10.4 und dann nach 10.6 Upgraden kann, um zu sehehn, ob das Problem damit weg ist?

[Mario]

Diese Versionen sind leider nicht mehr verfügbar.  Ich würde auch nicht annehmen dass es einen Unterschied macht.

[ChristopherFoto]

Ich habe mal noch nal einiges ausprobiert.
Es stellt sich für mich so dar, als ob die Oberfäche wenn ich eine Kategorie suche, in bestimmten Bereichen einfriert bzw. nicht mehr reagiert.
Ich such im Kategoriepanel über die Kategoriefilter Suche, solange das Ergebnis nicht angezeigt wird, kann ich im Kategoriepanel auf dem die Zuweisungen durchgeführt werden nicht arbeiten.
Auch funktioniert hier dann z.B. kein Rechtsklick auf eine Kategorie um dort z.B. zu sagen "Gehen zu Kategorie" das funktioniert erst wieder, wenn die Ergebnisse der Suche abgeschlossen ist.Die Bereiche "Medien & Dateien", "Zeitache" und "Kollektionen" funktionieren ganz normal, hier reagiert IMatch auch auf eine Rechtsklick um im Menü etwas auzuwählen, auch ist hier ein navigieren möglich und die entsprechnden Bilder werden sofort angezeigt. Wenn dann zurück zu "Kategorieen" gesprungen wird hat sich nichts geändert, eine Bedienung ist erst möglich, nachdemdie Suche abgeschlossen ist.

Auf diesen https://www.photools.com/community/index.php?topic=8371.0 Tread verweisend würde ich in meinem Fall ein klares nein aussprechen wollen.

Ich habe
31.130 Dateien
9.893 Kategorien
1.295 Verzeichnisse

[Mario]

Ich habe die Datenbank heruntergeladen und ein paar Tests durchgeführt.

Aktuelle offizielle IMatch-Version.
Datenbank auf einer meiner SSDs.
31077 Bilder, 9904 Kategorien.
Ladezeit: 4.2 Sekunden.
Alles gut.

A)

+ In die Kategorieansicht gewechselt.

Offen: Favoorites Panel. Category Panel. Metadata Panel, Quick View Panel. Dateifenster natürlich.

+ Im Kategoriefilter-Panel (unter dem Kategoriebaum links) den Suchbegriff Baiersbron eingegeben.
Keine Ergebnisse. Es wird nur noch @All angezeigt. Die Suche dauert ca. 1 Sekunde.

+ Filter geleert.
Baum baut sich in 1 Sekunde neu auf.

+ Filtere nach Erik
Baum baut sich in 1 Sekunde neu auf. Es werden vier Teilhierarchien angezeigt, für Erik und Erika.

+ Filtere nach a
Es werden ein paar Dutzend Kategorien im Baum angezeigt. Dauer: < 1 Sekunde.

+ Alle datengestützten Kategoren neu aufbauen.
+ Dauer: Ca 15 Sekunden.

+ Widerhilung aller Test von oben.
Vergleichbare Ergebnisse.

B)

Starten der aktuellen IMatch-Version auf Windows 10 in einer VM, "clean system".
Datenbank nun über simuliertes Netwerk (!) der VM angebunden.
Dieser simulierte Rechner ist sehr viel langsamer als mein Entwicklungsrechner.

+ Laden der DB dauert ca. 10 Sekunden. Zu erwarten.

+ Wiederholung der Tests von oben.
Nahezu gleiche Ausführunszeiten, (vielleicht 20% langsamer) wie erwartet. Das Filtern / Suchen im Kategoriebaum erfolgt im Speicher, ohne Festplattenzugriffe.

Ergebnis: Alles in Ordnung. IMatch performt super, wie erwartet mit einer so kleinen Datenbank. Selbst auf einem simulierten W10 in einer VM.

[ChristopherFoto]

Hallo Mario,
Danke für den Test, allerdings verwende ich nicht den "Filter:"  sondern den "Suchen:" also den oberen im Kategorien-Filter.
Mit dem Suchen im "Filter:" habe ich auch keine Probleme.

Siehe angehängten Screenshot

Gruß Christopher

[Mario]

Du schreibst immer "Filter", deshalb habe ich das kommentiert.
Tipp: Ein Screen shot wie von Sinus oder eine genaue Beschreibung, welche Schritte in welcher Reihenfolge in welchen Fenster usw. hilft sehr. Siehe meine Antwort oben als Beispiel.

Ich habe auch die Suchfunktion verwendet, ebenfalls ohne Probleme und super-schnell.
IMatch durchsucht den Baum so schnell ich auf "nächstes Ergebnis" klicken kann und zeigt die Inhalte der gefundenen Kategorien im Dateifenster an.
Ich habe nach Baiersbron gesucht (kein Fund), nach Erik und Mini.

Ich habe sogar alle Kategorien auf und wieder zugeklappt. Immer gleich, auf meinem Developer PC und der cleanen Windows10-Umgebung in der VM.

[ChristopherFoto]

Hallo Mario,
ja, mit der Beschriebung hast du zum Teil Recht, allerdings hatte ich auch schon auf Sinus antwort geschrieben, um welches Suchfeld es mir geht.
Mit dem in Screenshot angehängten rot markierten Suchen habe ich diese Probleme.

Das es bei Dir funktioniert glaube ich gerne, bei mir aber leider nicht und dies erst seit der Version 2018.10.6 mit der 2018.8.8 und davor hatte ich damit nie Probleme.
Irgendetwas scheint hier aber trotzdem nicht zu stimmen, gibt es noch weitere Debug-Möglichkeiten aus denen ersichtlich wird was IMatch macht, wenn es laut Debug-Log nichts macht aber 13-14% der CPU verwendet?

[Mario]

Das Log im Debug Mode ist das Maximum. Sonst hilft nur noch eine komplette Entwicklungsumgebung.

Da ich das nun auf zwei PCs nicht reproduzieren konnte und auch kein anderer User ähnliche Probleme meldet, schließe ich das ab, bis neue Erkenntnisse kommen. Ich habe noch viele andere Sachen auf meiner Liste und heute ist Sonntag.

[ChristopherFoto]

Hallo Mario,

ich habe nun noch mal etwas ausprobiert, da ich es so nicht lassen / akzeptieren wollte.
Dazu wurde von mir IMatch komplett deinstalliert, auch wurden die Verzeichnisse koplett gelöscht.
Nach wurde der PC neu gestartet und IMatch erneut in der Version 2018.10.6 installiert.
Nach dem Starten von IMatch kam dann die Abfrage die nach einer Erstinstallation kommt, auch diese wurde durchgeführt.
Im Anschluss habe ich meine Datenbank geöffnet und die üblichen Tests mit der Suche durchgeführt und siehe da nun funktioniert es ohne größeren Zeitversatz.
Auch die anschließenden Konfigurationsänderungen hatten keine Einfluss mehr auf die Suchgeschwindigkeit im Kategoriepanel.

Irgendetwas muss mit dem Update von 2018.8.8 auf 2018.10.6 geschehen sein, aber dem sei es so.

Nun funkioniert IMatch wieder wie gewohnt.
Noch mal vielen Dank für deine Unterstützung.

Gruß Christopher

[akirot]

Beobachte dasselbe Verhalten, habe dasselbe Problem.
11.000 Kategorien, 140.000 Files
2018.8.8 lief einwandfrei.
2018.10.4 habe ich quasi nicht verwendet.
2018.10.6 verwende ich jetzt, um neue Bilder einzupflegen.
Es wirkt so als ob der Kategoriebaum im Hintergrund immer neu berechnet wird - extrem hakelig (2018.8.8 lief pfeilschnell).
Außer MS-updates nichts verändert (die lassen sich leider nicht verhindern, empfinde es als Virus).
Werde es beobachten und ggf. berichten - habe gerade keine Zeit für Experimente.

[Mario]

Der Kategoriebaum wird immer im Hintergrund berechtet, das ist seit IMatch 5.0 so.
Was neu ist ist das das Berechnen der Counts nun in separaten Threads läuft und nicht mehr das UI blockiert. IMatch ist somit sehr viel responsive.

Was ist den "hakelig"? Welche Funktion? Welches Feature?
Ich arbeite ja selbst jeden Tag mit IMatch und mir ist nichts aufgefallen. Mit Ausnahme von bug #679, siehe release notes

[ChristopherFoto]

Hallo Mario,

ich habe nun noch mal etwas ausprobiert, da ich es so nicht lassen / akzeptieren wollte.
Dazu wurde von mir IMatch komplett deinstalliert, auch wurden die Verzeichnisse koplett gelöscht.
Nach wurde der PC neu gestartet und IMatch erneut in der Version 2018.10.6 installiert.
Nach dem Starten von IMatch kam dann die Abfrage die nach einer Erstinstallation kommt, auch diese wurde durchgeführt.
Im Anschluss habe ich meine Datenbank geöffnet und die üblichen Tests mit der Suche durchgeführt und siehe da nun funktioniert es ohne größeren Zeitversatz.
Auch die anschließenden Konfigurationsänderungen hatten keine Einfluss mehr auf die Suchgeschwindigkeit im Kategoriepanel.

Irgendetwas muss mit dem Update von 2018.8.8 auf 2018.10.6 geschehen sein, aber dem sei es so.

Nun funkioniert IMatch wieder wie gewohnt.
Noch mal vielen Dank für deine Unterstützung.

Gruß Christopher

Nun ist IMatch wieder so langsam wie zuvor, es hat sich nicht wirklich viel geändert.
Mal werden die Bilder relativ (3-5 Sekunden) schnell geladen, dann dauert es mal wieder bis zu 3 Minuten.
Eben habe ich auf 171 Bilder etwa 1 Sekunde gewartet, danach auf 7 Bilder 20 Sekunen, nun warte ich auf 192 Bilder 90 Sekunden, es ist einfach kein Schema zu erkennen.
Ich habe das Gefühl, wenn IMatch eine Weile läuft (3-5 Minuten) das es dann zu deulich weniger Verzögerungen kommt bzw. wenn einige Suchen (5-10) abgeschlossen sind es auch nicht mehr zu größeren Verzögerungen kommt.

In den Einstellungen unter Sonstiges habe ich auch mal die "Datengestütze Kategorie aktualisieren" ausgeschaltet, auch ohne Erfolg.
Auch alle anderen Hintergrundaktivitäten wurden ausgeschaltet, ebenfalls ohne Erfolg. 
 
Mir ist bewusst, das es für dich extrem schwirig ist das Problem zu lösen, wenn du es nicht nachstellen kannst.
In der Version 2018.8.8 und davor hatte ich das Problem niemals, erst mit der Version 2018.10.6

Das Log im Debug Mode ist das Maximum. Sonst hilft nur noch eine komplette Entwicklungsumgebung.

Da ich das nun auf zwei PCs nicht reproduzieren konnte und auch kein anderer User ähnliche Probleme meldet, schließe ich das ab, bis neue Erkenntnisse kommen.

Ich habe keine Ahnung, was ich dir noch liefern kann, so das dieses Problem gelöst wird.
Weitere Trace und Analysemöglichkeiten habe ich mit IMatch laut dir ja nicht.

[Carlo Didier]

Nur so aus dem Bauchgefühl: Hast Du schon mal die Event Logs von Windows gecheckt? Vielleicht ist da was zu sehn, falls das Problem nicht von iMatch direkt kommt (was nicht heisst dass es nicht mit der iMatch Version zusammenhängt).

[akirot]

Ich habe keine "eigenen" Data Driven categories, nur die IMatch samples.
In den preferences ist deren automatische Aktualisierung deaktiviert.
An allen Einstellungen habe ich seit etlichen IMatch Versionen nichts mehr geändert.

Folgendes Verhalten ist reproduzierbar:
- IMatch starten (im Media & Folders View, weil ich es so verlassen habe).
- Umschalten auf den Categories View
  -- View öffnet
  -- Zähler hinter den Kategorien sind für kurze Zeit alle auf (0/0)
  -- "Busy Wheel" unten rechts in Imatch dreht sich
  -- Nach wenigen Sekunden werden die Zähler aktualisiert (für die sichtbaren Kategorien)
  -- Das Aktualisieren der Zähler für alle! (auch gerade nicht sichtbaren) Kategorien läuft weiter.
  -- Nach ca. 1 Minute :-( ist die Aktualisierung des Kategoriebaums durch und die Bilder der ausgwählten Kategorie werden angezeigt.

Schaltet man dann zwischen Folder und Kategorieview hin und her hat man keine Verzögerung, da der Kategoriebaum nicht aktualisiert wird.
Arbeitet man an Bildern und verändert potenziell die Kategorien, startet wieder die volle Aktualisierung des Kategoriebaums sobald man auf die Kategoriesicht schaltet.
Umschalten mit CTRL+G von den Kategorien eines Bildes, um alle anderen Bilder mit derselben Kategorie zu sehen, ist damit faktisch nicht nutzbar (da es zu lange dauert)

Mit der Aktualisierung ist eine der acht virtuellen CPUs meines Rechners vollständig beschäftigt, die anderen sieben langweilen sich.

Meine DB hat ca. 8GB (lt. Info panel), der Rechner 32GB RAM.

Scheint u.a. ein Mengenproblem zu sein. Mit meiner Test DB (die nur wenige Hundert Bilder und Kategorien hat) fällt das verhalten nicht auf.

Vielleicht sollte man diesen Thread in Bugs verschieben?

[sinus]

Folgendes Verhalten ist reproduzierbar:

Komisch, ich kann das bei meiner DB beim besten Willen nicht reproduzieren.
Und meine DB hat 14 GB.

Hm, da kann ich leider eh nicht helfen.

[Mario]

Ich kann das nicht nachvollziehen. Auch nicht mit der von ChrstopherPhoto an mich gesendete Datenbank.

Ausnahme:

Das Aktualisieren der Zähler für alle! (auch gerade nicht sichtbaren) Kategorien läuft weiter.

Das wurde bereits als Bug gemeldet, besprochen für die nächste Version schon gefixed. Siehe Release Notes: https://www.photools.com/release-notes/

Mit der Aktualisierung ist eine der acht virtuellen CPUs meines Rechners vollständig beschäftigt, die anderen sieben langweilen sich.

Das ist normal. Windows Tree Controls nutzen nicht mehrere cores. Und das problem (s.o.) wurde dadurch ausgelöst das die UI lib die Texte aller Einträge anfordert. Auch der nicht sichtbaren.

[akirot]

Wenn der bug bereits behoben ist wäre es bitte schön, die neue Version kurzfristig zu bekommen (nicht erst im November, wie die Versionsnummer vermuten lässt) :-)

Ich hatte #679 nicht mit meinem Problem in Verbindung gebracht, da es sich dort im Westentlichen um data-driven categories (von denen ich nur die IMatch samples habe) dreht.

Um das Problem einmal anders zu beschreiben: So lange der Category view aktualisiert wird lässt sich keine Kategorie auswählen und damit die zugehörigen Bilder anzeigen. Das Aktualisieren dauert ca. 1 Minute. Aktualisiert wird fast immer - wenn ich wie jetzt permanent neue Bilder reinlade und kategorisiere. Das Verhalten war in den vorherigen IMatch Versionen anders/schneller.

[Mario]

Das nächste Update wird wie immer veröffentlicht sobald es fertig ist.
Es scheinen auch nur wenige Usr betroffen zu sein, sonst wäre die community vol mit Bug Reports.
Auf einem normalen PC mit 20,000 Kategorien betrug die Block-Zeit 9 Sekunden. Nicht eine Minute.Kann also durchaus was anderes sein. Etwas das ich hier auf zwei PCs nicht mal mit Christophers Originaldatenbank navhvollziehen konnte, auf seinem PC aber auftritt.

[akirot]

Hab's weiter eingrenzen können:
Wenn man den category view umkonfiguriert, dass er die counts nicht anzeigt ist die Performance vollkommen in Ordnung.

Folgendes ist auch reproduzierbar:
Hat man den category view ohne counts konfiguriert und konfiguriert dann um, dass er die counts anzeigt, läuft IMatch los und ermittelt die zugehörigen Mengen - das dauert dann in meinem Fall ca. eine Minute bis IMatch durch ist und die Bilder zu der ausgewählten Kategorie zeigt.

Ich habe etliche "Alias" in meinen Kategorien - vielleicht hilft das bei der Ursachensuche?

(Datenbankdiagnose und Compact & Optimize laufen problemlos durch.)

Ein I7-6700K ist kein langsamer PC ;-)

[ChristopherFoto]

Hab's weiter eingrenzen können:
Wenn man den category view umkonfiguriert, dass er die counts nicht anzeigt ist die Performance vollkommen in Ordnung.

Danke für den Hinweis, darauf bin ich nicht gekommen.
Ja, dem stimme ich völlig zu, ist bei mir auch so.
Wenn ich in den Kategorien die Zähler ausschalte, habe ich keinerlei Performacprobleme mehr, hab dies nun mehrfach gestern und heute ausprobiert, damit ist IMatch 10.6. wieder genau so performant wie die 8.8er Version.

Mit Ausnahme von bug #679, siehe release notes

Ist das das gleiche / unser Problem?