ListView Performance bei vielen Datensätzen (FMX)

[fisipjm]

Zitat von dummzeuch:

Zitat von fisipjm:

Diese Funktion braucht für 138902 Datensätze 2309 ms zum einfügen in die Listview. Das sind 60 Einträge pro ms. Deshalb "langsam" in Anführungszeichen.

Ich würde das zum Timing mal auseinandernehmen:
1. Lesen aus der Query (in lokale Dummy-Veriablen)
2. Schreiben (von Dummy-Werten) in das Listview, so viele, wie die Query Einträge hat

Danach weißt, du, wie hoch der Anteil der jeweiligen Funktionalität ist. Darauf basierend kann man dann nach weiterer Optimierung suchen.

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. :-/

[Papaschlumpf73]

Chat-GPT glaubt, dass es auch beim FMX-ListView einen VirtualMode gibt: ListView1.OnUpdateObjects
Wenn das stimmt (wie schon erwähnt, hab ich keine Ahnung von FMX), könnten 2 der 3 Prozesse extrem beschleunigt werden. Selbst das Visible:=true wäre dann extrem schnell.

[dummzeuch]

Zitat von fisipjm:

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 )

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.

[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

[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.