ListView Performance bei vielen Datensätzen (FMX)

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

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

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?

[fisipjm]

Zitat von 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?

Das "Bottleneck" ist 2 geteilt. Wie gesagt, das öffnen der Query ist nicht das Problem. Die Ist zu diesem Zeitpunkt schon lange offen. Das einzige was ich noch mache ist ein Query.first das geht unter 1ms.
Was "lange" braucht ist

Delphi-Quellcode:

while not Query.Eof do
        begin
          lListViewItem := ListView.Items.Add;
          lListViewItem.Objects.FindObjectT<TListItemText>('Field1').Text := lField1.AsString;
          lListViewItem.Objects.FindObjectT<TListItemText>('Field2').Text := lField2.AsString;
          lListViewItem.Objects.FindObjectT<TListItemText>('Field3').Text := lField3.AsString;
          lListViewItem.Objects.FindObjectT<TListItemText>('Field4').Text := lField4.AsString;
          lListViewItem.Tag := Query.RecNo;
          Query.Next;
        end;

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.

Der 2. Aufruf der "Lange" dauert ist das Anzeigen der Listview, also das setzen von Listview.Visible = true. Das dauert 907 ms. Auch hier ist deshalb langsam in Anführungszeichen geschrieben.

Nochmal zum Thema SQL. Die Query ist bereits geöffnet (Filter werden direkt nach der Anmeldung gesetzt und öffnen wird im Hintergrund durchgeführt) , also keine Möglichkeit hier sehr sicher keine Optimierung zu erreichen.

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

[Papaschlumpf73]

Von dem FMX-Dingern hab ich keine Ahnung. Aber kann man sich die 4 Spalten nicht vorab irgendwie merken, statt sie bei jedem Datensatz mit FindObjectT... neu zu suchen?

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