Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Performance ListView vs. StringGrid (https://www.delphipraxis.net/51448-performance-listview-vs-stringgrid.html)

Sven Janssen 12. Aug 2005 13:40


Performance ListView vs. StringGrid
 
Hallo.

Ich hätte es ja nicht für möglich gehalten, aber beim eintragen von ca 3000-5000 Zeilen a 7-10 Spalten ist ein ListView nicht zu gebrauchen.
Das Eintragen dauert ca 5 Minuten (oder eher mehr) auf einem P4 mit 3GHZ, wobei ein Stringgrid in ein paar Sekundengefüllt ist.
Eintargen tun wir die Daten wie folgt:
Delphi-Quellcode:
var nitem:TListItem;
begin
.
.
c:=3000;
for i:=1 to c do begin
    nitem:=ListView1.items.add;
    nitem.caption:=inttostr(i);
    nitem.subitems.add(inttostr(i)+'-1');
    nitem.subitems.add(inttostr(i)+'-2');
    nitem.subitems.add(inttostr(i)+'-3');
end;
Wie gesagt ein grobes Beispiel.
vielleicht ist die Logik auch nur verkehrt.

Sven

Bernhard Geyer 12. Aug 2005 13:45

Re: Performance ListView vs. StringGrid
 
BeginUpdate/EndUpdate nicht vergessen.
Sonst wird nach jedem Datensatz das ListView neu gezeichnet

Keldorn 12. Aug 2005 13:47

Re: Performance ListView vs. StringGrid
 
Hallo

5 Minuten? das ist arg viel, das liegt nicht bloß am Füllen, wo kommen die Daten her?

Geschwindigkeit bringt u.a.:
Delphi-Quellcode:
listview1.Items.BeginUpdate;
...
Befüllen
...
listview1.Items.endUpdate;
außerdem solltest du die Spaltenbreiten nicht automatisch anpassen lassen (columntextwidth etc.), das kostet auch immens viel Zeit, vormn Füllen einfach wieder auf feste Werte setzten und nach dem Befüllen wieder anpassen lassen.
Oder du schaust dir die Verfahrensweise bei virtuellen Listviews an.

Mfg Frank

alzaimar 12. Aug 2005 13:49

Re: Performance ListView vs. StringGrid
 
Virtuelle Listviews sind sowieso am schnellsten 'befüllt', das würde ich ja machen.

Sven Janssen 12. Aug 2005 13:53

Re: Performance ListView vs. StringGrid
 
Zitat:

Zitat von Bernhard Geyer
BeginUpdate/EndUpdate nicht vergessen.
Sonst wird nach jedem Datensatz das ListView neu gezeichnet

ja sorry, ist natürlich gesetzt.
Die Listview wird auch vor dem show befüllt.

Sven

Sven Janssen 12. Aug 2005 13:56

Re: Performance ListView vs. StringGrid
 
Zitat:

Zitat von Keldorn
Hallo

5 Minuten? das ist arg viel, das liegt nicht bloß am Füllen, wo kommen die Daten her?

Aus einem TIBDataSet.
Aber wie gesagt, aus der gleichen Quelle wird auch das Stringgrid befüllt
Zitat:


Geschwindigkeit bringt u.a.:
Delphi-Quellcode:
listview1.Items.BeginUpdate;
...
Befüllen
...
listview1.Items.endUpdate;

Sorry hatte ich vergessen zu poste. Wird immer gesetzt.
Zitat:

außerdem solltest du die Spaltenbreiten nicht automatisch anpassen lassen (columntextwidth etc.), das kostet auch immens viel Zeit, vormn Füllen einfach wieder auf feste Werte setzten und nach dem Befüllen wieder anpassen lassen.
und genau da könnte das Problem liegen. Genau das mache ich nämlich.
Werde das nachher direkt einmal testen und das automtische Anpassen der Spalten erst im nachhinein machen.

Sven

Bernhard Geyer 12. Aug 2005 13:57

Re: Performance ListView vs. StringGrid
 
Zitat:

Zitat von Sven Janssen
Zitat:

Zitat von Bernhard Geyer
BeginUpdate/EndUpdate nicht vergessen.
Sonst wird nach jedem Datensatz das ListView neu gezeichnet

ja sorry, ist natürlich gesetzt.
Die Listview wird auch vor dem show befüllt.

Sven

Dann hätte ich noch folgendes Anzubieten:

- Virtuelle ListView (Beispiel in Demoverzeichis von Delphi dabei)
- VirtualTreeStringGrid (Is jedoch mit einigen Aufwand verbunden sich damit auseinanderzusetzen)
- TElTree (Kostet jedoch ein paar €, dafür fast identisch zu TTreeView zu programmieren)

ibp 12. Aug 2005 13:58

Re: Performance ListView vs. StringGrid
 
Delphi-Quellcode:
var nitem:TListItem;
  zahl:string;
begin
.
.
c:=3000;
for i:=1 to c do begin
    zahl:=inttostr(i); //<- nur einmal anstatt 4 mal!
    nitem:=ListView1.items.add;
    nitem.caption:=zahl;
    nitem.subitems.add(zahl+'-1');
    nitem.subitems.add(zahl+'-2');
    nitem.subitems.add(zahl+'-3');
end;
sollte auch schon ein wenig bringen!

Sharky 12. Aug 2005 14:00

Re: Performance ListView vs. StringGrid
 
Zitat:

Zitat von Sven Janssen
Hallo.

Ich hätte es ja nicht für möglich gehalten, aber beim eintragen von ca 3000-5000 Zeilen a 7-10 Spalten ist ein ListView nicht zu gebrauchen.
Das Eintragen dauert ca 5 Minuten (oder eher mehr) ...

Hai Sven,

ich habe es eben mal getestet:
ListView mit 7 Columns und 3000 Zeilen. Ohne BeginUpdate ca. 2.5 Sekunden. Mit BeginUpDate 1.7 sekunden.

Sven Janssen 12. Aug 2005 15:10

Re: Performance ListView vs. StringGrid
 
Zitat:

Zitat von ibp
Delphi-Quellcode:
var nitem:TListItem;
  zahl:string;
begin
.
.
c:=3000;
for i:=1 to c do begin
    zahl:=inttostr(i); //<- nur einmal anstatt 4 mal!
    nitem:=ListView1.items.add;
    nitem.caption:=zahl;
    nitem.subitems.add(zahl+'-1');
    nitem.subitems.add(zahl+'-2');
    nitem.subitems.add(zahl+'-3');
end;
sollte auch schon ein wenig bringen!

hehe, ne Du das ist nicht der Code aus dem Programm.
Das war ein Beispiel wie ich genau den Inhalt in das ListView bekomme.

@sharky
Wie gesagt es könnte an dem automatischen Anpassen der Spaltenbreite liegen.
Das sind Postleitzahlen + Namen aus einer Datenbank. Sprich sehr unterschiedliche größen.

Ich kam leider eben nicht mehr dazu es zu testen. Ich habe mir mal fix das Demo zu den Virtuellen ListViews angeschaut und das kommt mir sehr vertraut vor. Wenn ich das richtig gesehen hab, ist dabei das Daten und Ausgabe Modell getrennt. Die Logik kenne ich aus Cocoa und hatte sie eigentlich vermisst beim TListView.
Hier zuhause kann ich es nicht testen, da ich hier keine Windows Maschine hab. Aber ich berichte dann am Montag.

Sven


Alle Zeitangaben in WEZ +1. Es ist jetzt 20:02 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz