ListView Performance bei vielen Datensätzen (FMX)

[dummzeuch]

Zitat:

Zitat von fisipjm (Beitrag 1538946)

Also, hab das jetzt noch weiter Auseinander genommen.
Laden der Daten in 3 unterschiedliche TArray<String> Variablen - 620 ms
Laden des Arrays in die Listview mit "add" befehl - 1611 ms
Umstellen auf Visible=true - 1140 ms

Zusammen 3371 ms
Am meisten "stören" tatsächlich die 1140 ms im Visible:=true teil, weil da auch die Ladeanimation hängt. :-/

OK, es liegt also tatsächlich hauptsächlich am ListView.

Und dummerweise fällt mir auf Anhieb auch erstmal keine Lösung ein, weder für's Einügen noch für's sichtbar machen.

Vermutlich müsste man jetzt mal nachsehen, was dieses Anhängen der Zeilen bzw. einfügen der Daten in eine Zeile eigentlich macht. Ich könnte mir vorstellen, dass der Hinweis auf den ständigen Lookup nach dem Namen von @Papaschlumpf73 durchaus seine Berechtigung hat. Wenn man das anders lösen könnte ...

Aber da bin ich jetzt ziemlich raus, da meine Erfahrung mit FMX bisher auch eher homöopathisch ist.

Ich frage mich allerdigs gerade, ob man die Animation nicht irgendwie doch im Hintergrund abspielen könnte. Unter Windows/VCL würde ich mir zutrauen das irgendwie hinzuhacken, aber unter FMX? Aber vielleicht gibt es ja gerade unter FMX sogar eine einfachere Möglichkeit dazu, nur kenne ich die nicht.

[fisipjm]

Okay, neuer Zwischenstand und neue Erkenntnisse.

Es gibt 2 Dinge die ich in der ListView noch optimieren kann, die dazu führen, dass die Zeit (zumindest die, die ich messen kann, näheres gleich) drastisch sinkt.
Ich hatte als Einstellung für die Items die ListView auf dynamic appearance gestellt und Sie entsprechend angepasst. Hab mir jetzt überlegt, ich brauche nicht notwendigerweise 4 Felder, 2 tun es auch. Dadurch kann ich die Listview umstellen auf die Ansicht mit Detailbereich. Dadurch kann ich auf das Find verzichten und direkt das Text und Detail Property ansprechen. Das drückt die Zeit zum SChreiben auf ca. 500ms.

Wenn ich das Allign der Listview auf "none" stelle, wird für das Visible eine glatte 0ms. (Danke an Alister Christie mit seinem aktuellsten youtube Video für die Idee :lol:)

jetzt zu dem Punkt warum ich sage, die die ich messen kann. Ich habe mich mit der Stopuhr daneben gestellt. obwohl ich mit TStopWatch arbeite und mir die Messwerte in Summe unter 1 sec. ausspucken, braucht die Form doch ca. 4 Sekunden bis fertig geladen und angezeigt ist. Habt ihr eine Idee woran das liegen kann? Ich bin im OnShow Event schon durch wenn ich die Messergebnisse angezeigt bekomme.:pale:

[fisipjm]

Vielleicht weis jemand wo ich noch schauen kann, bzw. optimieren kann.
Ich hab jetzt mal getestet wie sich die Form verhält, wenn sie einmal dargestellt wurde und dann einfach mit hide und show wieder angezeigt wird. Das Funktioniert top. Nur das erste Öffnen dauert weiterhin 3-4 Sekunden.
Ich hab jetzt aber absolut keinen Plan mehr, wo ich ansetzen kann.
Im OnShow Ereignis der Form steht gar nichts mehr drin. Die Form ist dann für 3-4 Sekunden weis, danach sehe ich die gefüllte Listview. Ich bin auch schon mal in die ListView in einige Ereignisse mit dem Debugger rein, aber die laufen alle ohne Verzögerung. Ich finde den Prozess, der hier verzögert einfach nicht :-(

[Papaschlumpf73]

Gibts für die LIstView selbst oder eine der Spalten oder die Items noch irgendwo Align, AutoSize oder AutoIrgendwas?

[fisipjm]

Hoi, gibts leider nicht :-(

Ich hab mich jetzt durch die FMX.Listview durchgewühlt.
Die Aufrufzeit von ca. 3-4 sec verteilt sich ziemlich genau zu je 1/3 auf folgende Funktionen

procedure TListViewBase.DrawListItems(const AbsOpacity: Single);
procedure TAppearanceListView.ApplyStyle;
procedure TListViewBase.ApplyStyle;

Ich befürchte, dass es sich nicht lohnen wird hier weiter zu optimieren. Ich habe jetzt einen Workaround gemacht, der mir zwar nicht ganz schmeckt, aber den ich jetzt so nehmen werde. Das Anzeigen dauert nur beim ersten mal so lange. Die Form wird jetzt erzeugt und hat eine Meldung die Angezeigt wird "Anzeige wird vorbereitet". Diese form wird dann während der Lebenszeit der Anwendung nicht mehr gelöscht, sondern nur noch mit Hide ausgeblendet. Man muss also beim ersten mal öffnen die 3-4 Sekunden warten und im Anschluss ist es jedes mal direkt da.
Wenn ich gar nicht drum herum komme, werde ich eine eigene Filterlogik implementieren die dann schon beim Aufruf greift. Besonders blöd an der Stelle finde ich, dass alles beim Anzeigen der Komponente passiert. Das läuft natürlich alles im Hauptthread und da kanns mir passieren, dass die Anwendung dann fliegt, wenns dem OS zu lange dauert. Ich habe aber nicht wirklich Möglichkeiten hier einzugreifen, ohne die DMX-ListView selbst anzupassen, oder mir irgendwie abzuleiten. Naja, trotzdem danke für euer Feedback und Input :thumb:

[Papaschlumpf73]

Machst du ein Feature draus. Die Software merkt sich immer den letzten Filter und wenn es noch keinen gab, gibst du einen "Mustermann"-Filter oder was da sonst so passt vor.

[fisipjm]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1538981)

Machst du ein Feature draus. Die Software merkt sich immer den letzten Filter und wenn es noch keinen gab, gibst du einen "Mustermann"-Filter oder was da sonst so passt vor.

Was da sonst so passt, kann ich nicht bestimmen. Das ist davon abhängig was der Kunde in seine Datenbank wirft. Das ist ja genau der Grund, warum ich auch gerne die Möglichkeit hätte die ganze Liste anzuzeigen.
Kennst ja sicher die Kunden die dir auf "hier müssen sie einen Filter vorgeben" antworten mit, "aber woher weis ich denn nach was ich filtern kann".
So in die Richtung geht das:roll:

[Papaschlumpf73]

Zitat:

Zitat von fisipjm (Beitrag 1538982)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1538981)

Machst du ein Feature draus. Die Software merkt sich immer den letzten Filter und wenn es noch keinen gab, gibst du einen "Mustermann"-Filter oder was da sonst so passt vor.

Was da sonst so passt, kann ich nicht bestimmen. Das ist davon abhängig was der Kunde in seine Datenbank wirft. Das ist ja genau der Grund, warum ich auch gerne die Möglichkeit hätte die ganze Liste anzuzeigen.
Kennst ja sicher die Kunden die dir auf "hier müssen sie einen Filter vorgeben" antworten mit, "aber woher weis ich denn nach was ich filtern kann".
So in die Richtung geht das:roll:

Das ist blöd... Solche Kunden hab ich auch. Mi, mi, mi, das war früher aber anders. Oft haben sie sich aber nach ein paar Tagen oder Wochen daran gewöhnt.

[Uwe Raabe]

Das Anzeigen aller Daten in einer Liste mit 138.000 Einträgen, die der Kunde eh nicht in ihrer Gänze verarbeiten kann, zeugt in der Regel von einem Informationsdefizit, was der Kunde wie oft von der Liste wissen will.

Das ist natürlich stark von dem konkreten Anwendungsfall abhängig, aber mit etwas Recherche und ggf. dem Kunden bei der Arbeit über die Schulter gucken kann man schon so einiges herausfinden.

Handelt es sich z.B. um über einen langen Zeitraum erfasste Einträge, sind eventuell nur die letzten Tage, Wochen oder Monate überwiegend im täglichen Gebrauch relevant. Dann wäre vielleicht ein entsprechender Filter als Default geeignet. Für ältere Einträge aus einem bestimmten Zeitraum muss der Kunde diesen eben angeben.

Anderer Fall: Es handelte sich um eine Liste mit Adress- und Kontaktdaten. Dann wäre eine Eingabemaske mit bestimmten Suchkriterien die erste Wahl (Stichwort: QBE).

Leider kann der Kunde diese Art von Anforderungen meistens nur schwer oder gar nicht kommunizieren. Auf eine Frage wie "Was brauchst du am häufigsten?" folgt oft die Angst, dass alles was darauf nicht genannt wird dann später auch nicht möglich ist. Da hilft dann halt nur Zusehen und Nachfragen.

[Papaschlumpf73]

Zitat:

Zitat von Uwe Raabe (Beitrag 1538984)

Da hilft dann halt nur Zusehen und Nachfragen.

So ist das... Und wenn man darin ziemlich gut ist, meckert auch keiner, wenn mal was nicht so gut auf Anhieb funktioniert.