ListView Performance bei vielen Datensätzen (FMX)

[fisipjm]

Hi,

ich bin auf der Suche nach Ideen für eine "bessere" Lösung. Aktuell habe ich eine ListView, die liegt auf einer Form die erst beim öffnen erstellt wird. Also nicht nur Visible True gesetzt wird, sondern wirklich über ein Create erstellt wird und danach wieder mit caFree entfernt wird. Das sollte auch so bleiben, da diese Logik sich durch das gesamte Projekt zieht. Das als Info vorneweg :)

Also ich lade aktuell in diese Listview beim on Show der Form die Daten Asyncron in die ListView (Ja, das geht weil ich Sie vorher auf visible=false setzte und ein Ladekreis drüber lege). Die Listview hat 4 Felder und erhält ca. 138.000 Einträge. Das geht in ca. 3 Sekunden.

Es gibt nun 2 Sachen die mich "stören".
1.) Die 3 Sekunden :lol: wenn ihr also eine Idee habt wie man noch schneller Daten in eine ListView laden kann und darstellen kann, immer her damit :)
2.) Das Listview.visible := true setze ich am Schluss meines Ladethreads innerhalb eines TThread.Synchronize weil das dann die Änderung an der Form sichtbar macht. Dieser Vorgang dauert auch nochmal ca. 2 sekunden. Also bis die Listview gezeichnet ist.

Habt ihre eine Idee, wie man da noch was rauskitzeln kann? Ich bin im FMX Umfeld unterwegs.
vG
PJM

[himitsu]

Zitat:

visible=false ... asyncrhon

NEIN,
aber das Items hat ja auch noch ein BeginUpdate und EndUpdate.

Wie auch bei der VCL, würde ich hier noch mehr davon ausgehn, dass es grundsätzlich nicht threadsafe ist, aber ordentlich getrennt, sollte es dennoch halbwegs sicher sein.



Warum will man überhaupt so viel da reinladen?
Dynamisch nachladen oder via einem Filter nur so viel, wie der Mensch verkraftet.

[fisipjm]

Zitat:

Zitat von himitsu (Beitrag 1538907)

Zitat:

visible=false ... asyncrhon

NEIN,
aber das Items hat ja auch noch ein BeginUpdate und EndUpdate.

Wie auch bei der VCL, würde ich hier noch mehr davon ausgehn, dass es grundsätzlich nicht threadsafe ist, aber ordentlich getrennt, sollte es dennoch halbwegs sicher sein.

Ja hast du natürlich recht, ich bin ebenfalls im BeginUpdate und im Endupdate drin. Mein "Problem" ist, wenn ich nur das BeginUpdate und EndUpdate verwende und nicht visible=False. ist die ListView an der Stelle schon mal nicht mehr ThreadSafe und ich muss das Erzeugen der Objekte im Mainthread machen, was wiederum dazu führt, das meine Ladeanimation hängt.

Zitat:

Warum will man überhaupt so viel da reinladen?
Dynamisch nachladen oder via einem Filter nur so viel, wie der Mensch verkraftet.

Das ist eine Auswahllist für Objekte aus denen der Benutzer auswählen können soll. Es gibt auch Favoriten, die dann über das SQL gesteuert an oberster Stelle stehen. Die Such/Filterfunktion der Listview gefällt mir sehr gut und ist auch bei dieser Datenmenge ausreichend performant und ich wollte mir den "Aufwand" sparen den Filter über das SQL zu implementieren. Außerdem sieht es "schicker" aus, wenn sich die Seite öffnet und bereits Datengeladen sind, anstatt erst nach was suchen zu müssen und dann überhaupt erst zu sehen, was für Werte zur Auswahl stehen.

[Papaschlumpf73]

Zitat:

Zitat von fisipjm (Beitrag 1538915)

Die Such/Filterfunktion der Listview gefällt mir sehr gut und ist auch bei dieser Datenmenge ausreichend performant und ich wollte mir den "Aufwand" sparen den Filter über das SQL zu implementieren.

Mein ListView hat keine Filterfunktion oder habe ich da etwas übersehen? Ups, hab ich übersehen, ist ja für FMX - da gibts vielleicht eine Filterfunktion.

Der Vorschlag von himitsu, die ListItems dynamisch zu laden, ist m.E. aber der einzige Weg, das wirklich schnell zu machen. Dann müsste man natürlich die Such- und Filterfunktionen neu basteln. Das sieht dann auch so aus, als wären alle Einträge im ListView enthalten; tatsächlich kennt das ListView aber nur die ListItems, die gerade sichtbar sind.

[Papaschlumpf73]

Zusätzlich kann man ggf. auch noch die Ermittlung der Datensätze aus der SQL-Datenbank optimieren.

• Optimierung der SQL-Abfrage selbst, damit der DB-Server das Ergebnis schneller ausliefert
• Wenn man die SQL-Ergebnisse in irgendeinem DataSet mit "while not eof - next" durchläuft, kann "AutoCalcFields:=false" des DataSets enorme Performance bringen, selbst wenn es gar keine berechneten Felder gibt.
• Noch viel schneller lassen sich so große Datenmengen z.B. per ADO mit TADOQuery1.Recordset.GetRows(...) direkt in ein großes Array laden, ohne Schleife und Next usw.

[QuickAndDirty]

Wenn die Datensätze aus einer SQL Datenbank kommen, dann kann man sie auch "per page" laden.
In dem man immer die nächsten 50 oder die vorherigen 50 fetched und das Fetch offset entsprechend mit verschiebt.

[fisipjm]

Zitat:

Zitat von QuickAndDirty (Beitrag 1538920)

Wenn die Datensätze aus einer SQL Datenbank kommen, dann kann man sie auch "per page" laden.
In dem man immer die nächsten 50 oder die vorherigen 50 fetched und das Fetch offset entsprechend mit verschiebt.

Ja, aber da greift wieder der Punkt mit dem Filter. Ich hatte gehofft es umgehen zu können eine eigene Filterfunktion zu schreiben.

[fisipjm]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1538919)

Zusätzlich kann man ggf. auch noch die Ermittlung der Datensätze aus der SQL-Datenbank optimieren.

• Optimierung der SQL-Abfrage selbst, damit der DB-Server das Ergebnis schneller ausliefert
• Wenn man die SQL-Ergebnisse in irgendeinem DataSet mit "while not eof - next" durchläuft, kann "AutoCalcFields:=false" des DataSets enorme Performance bringen, selbst wenn es gar keine berechneten Felder gibt.
• Noch viel schneller lassen sich so große Datenmengen z.B. per ADO mit TADOQuery1.Recordset.GetRows(...) direkt in ein großes Array laden, ohne Schleife und Next usw.

Da ist, befürchte ich, nicht mehr viel Luft nach oben. Es sind nur die Felder die selektiert werden auch in der SQL Abfrage, ohne Sortierung.
Außerdem liegt der Dataset bereits geöffnet auf meinem TDataModule. Habe also keinen Overhead für das Öffnen des Datasets. Die CalcFields sind aus, haben aber auch keinen Impact auf die Ladezeit (getestet).
Ich gehe in einer EOF schleife durch. Könnte mal versuchen mit einer for schleife die RecNo zu setzen, vielleicht fallen dadurch noch ein paar Prüfungen die im Next durchgeführt werden weg.

[dummzeuch]

Jetzt bin ich verwirrt. Liegt das Performance-Problem beim Einfügen der Daten in den ListView oder beim Auslesen der Daten aus der Datenbank?

(Ja, ich weiß, ich habe mich bisher nicht sinnvoll beteiligt, nur mitgelesen.)

[TurboMagic]

Ja, das wäre eine Untersuchung wert: wo ist das Bottleneck?
Laden aus der DB oder Einfügen in das Listview?
Ich gehe auch davon aus, dass die where Begingung des Selects
einen passenden Index in der DB nutzen kann?