FMX Listbox total lahm

[wurzelzwerg]

Das Füllen einer FMX-Listbox mit 8000 Einträgen dauert ganze 36 Minuten. :shock:
(VCL unter 1 sec)
Gibts da evtl Alternativen?

[Union]

1753 ms:

Delphi-Quellcode:

procedure TfrmIosMain.FormCreate(Sender: TObject);
var
  i : integer;
  dtStart : TDateTime;
begin
  dtStart := Now;
  for i := 0 to 7999 do
    ListBox1.Items.Add(Format('%8.8d', [i]));
  ShowMessage(Format('%d', [MilliSecondsBetween(Now, dtStart)]));
end;

Liegt es vielleicht nicht an der Listbox sondern daran wie Du die Daten erstellst?

[wurzelzwerg]

Kann es sein dass du ne IOS-App hattest? Ich hatte ne Firemonkey-HD-Anwendung.
Als IOS-App dauert dein code bei mir 5625 ms.
Ich hatte zum Test auch nur das hier:

Delphi-Quellcode:

s:= '1,2,3,4,5,6,7';
for i := 0 to 8000 do
  ListBox1.Items.Add(s);

[Union]

Frische FMX-HD Anwendung:

Delphi-Quellcode:

uses DateUtils;
{$R *.fmx}

procedure TForm3.FormCreate(Sender: TObject);
var
  i : integer;
  dtStart : TDateTime;
begin
  dtStart := Now;
  for i := 0 to 7999 do
    ListBox1.Items.Add(Format('%8.8d', [i]));
  ShowMessage(Format('%d', [MilliSecondsBetween(Now, dtStart)]));
end;

2425 ms.

Delphi-Quellcode:

ListBox1.BeginUpdate;
for i := 0 to 7999 do
  ListBox1.Items.Add(s);
EndUpdate;

1690 ms. Hast Du vielleicht ein OnChange oder sowas an der Listbox?

[wurzelzwerg]

Nö, nichts dran. Die Schleife ist der einzige Code.
Werd mal nen anderen PC probieren. :gruebel:

Edit: Mist, kann das XE nicht nochmal installieren(nur Trial)

[Union]

Kannst ja mal das komplette Miniprojekt anhängen. Dann kann man es mal prüfen ob irgendwas Absonderliches drin steckt. Ansonsten wäre es hilfreich was über den Rechner zu erfahren (OS, Prozessor, Speicher, VM) und vielleicht auch mal Laufzeitmessungen zu machen (Prozessor, Speicher, HD). Und da ja FMX GPU orientiert ist: GRAFIKKARTE und Treiber! Ja, das kommt dann auch auf uns zu dass wir den Kunden bei Problemen nach der Version seiner GK-Treiber fragen müssen.

[wurzelzwerg]

OK, hier mal das Miniprojekt.
Und die PC-Daten:
AMD 64X2 Dual
4200+
2,21 GHz
2 GB
Windows XP SP3
GraKa: RadeonX1800GTO
256MB

Wo kann man den Treiber auslesen? Ich seh nur ATI-Display-Driver.

Auf meinem MacBookPro hab ich dasselbe Problem, OSX und WindowsXP.
Häng bitte mal eine .exe von dir ran, vielleicht geht die ja.

[Union]

Es scheint exponentiell von der Anzahl der Elemente der Listbox abzuhängen. Versuch es mal mit Begin/Endupdate, ich habe jetzt dabei eine Geschwindigkeitssteigerung um das 250-fache gemessen :

Code:

Listbox alClient (600x400) mit 1000 Elementen = 5223 ms
ListBox alClient (600x400) mit 2000 Elementen = 28809 ms

ListBox alClient (600x400) mit 2000 Elementen Begin/Endupdate = 109 ms
ListBox alClient (600x400) mit 8000 Elementen Begin/Endupdate = 1704 ms

Delphi-Quellcode:

procedure TfrmMain.FormCreate(Sender: TObject);
var
  i : integer;
  dtStart : TDateTime;
begin
  dtStart := Now;
  ListBox1.BeginUpdate;
  for i := 0 to 7999 do
    ListBox1.Items.Add(Format('%8.8d', [i]));
  ShowMessage(Format('%d', [MilliSecondsBetween(Now, dtStart)]));
  ListBox1.EndUpdate;
end;

Ich habe aber nur 32bit runtime. Hast Du vielleicht 64 erstellt? Das kann ich bei mir nicht testen.

[Union]

Ich habe Deine Anwendung getestet und nach 5 Minuten mit 100% CPU gekillt. Bei mir kompiliert das selbe. Dann Begin/EndUpdate eingefügt. 3160 ms.

[wurzelzwerg]

Komisch. Was ist denn zu deinem ersten Test anders?

Mit Begin/Endupdate sind es jetzt 5219ms. Schon mal wesentlich besser. VCL: 1150ms
Das Scrollen in der Box ist aber auch keine Freude.

[Union]

Das Scrollen ist schon in qc. Der Unterschied zu heute nacht ist die Größe der Listbox. Die hatte ich einfach aus der Palett eingefügt und unverändert auf 100x100 gelassen.

Und hier sehen wir sehr schön den Unterschied zwischen dem bösen HEAVYWEIGHT:

Delphi-Quellcode:

Result := SendMessage(ListBox.Handle, LB_ADDSTRING, 0, Longint(PChar(S)));

und dem tollen, neuen LIGHTWEIGHT:

Delphi-Quellcode:

Item := TListBoxItem.Create(FListBox);
try
  Item.Text := S;
  Result := FListBox.Count;
  FListBox.AddObject(Item);

[wurzelzwerg]

Hmm. Die Grösse macht bei mir keinen Unterschied.

[Union]

Und dann rate mal was TCustomListBox.Getcount macht :(

[generic]

Macht es Sinn 8000 Einträge in einer Listbox anzuzeigen?
Wer soll das alles lesen?
Wie lange soll das Dauern?
Der arme User bekommt bestimmt Gicht in den Fingern vom Mausrad drehen.

[wurzelzwerg]

Zitat:

Macht es Sinn 8000 Einträge in einer Listbox anzuzeigen?

Nicht wirklich. Das ist ne Umsetzung von nem alten Projekt, wo das so war.
Ich werde das jetzt anders machen.

[Union]

Du könntest es durch ein StringGrid erzeugen. Das ist seltsamerweise rasend schnell, obwohl viel komplexer.

[Union]

Können mal bitte ein paar XE2 User die Samples\Firemonkey\CustomListBox Demo öffnen und dann folgendes tun:

1. F9 drücken
2. "Add 1000 by code" Button
3. mit den Pfeiltasten in der Listbox ganz nach unten scrollen
4. mit den Pfeiltasten in der Listbox ganz nach oben scrollen
5. Schritte 3 und 4 möglichst oft wiederholen

Während der Laufzeit den Speicher den die Anwendung benötigt beobachten.

[bernau]

Zitat:

Zitat von Union (Beitrag 1127586)

Können mal bitte ein paar XE2 User die Samples\Firemonkey\CustomListBox Demo öffnen und dann folgendes tun:

1. F9 drücken
2. "Add 1000 by code" Button
3. mit den Pfeiltasten in der Listbox ganz nach unten scrollen
4. mit den Pfeiltasten in der Listbox ganz nach oben scrollen
5. Schritte 3 und 4 möglichst oft wiederholen

Während der Laufzeit den Speicher den die Anwendung benötigt beobachten.

Ja kann ich bestätigen. Der Speicherverbrauch steigt enorm.

[FredlFesl]

Delphi XE2 + FMX = Spitzenprodukt :mrgreen:

[Union]

Zitat:

Ja kann ich bestätigen. Der Speicherverbrauch steigt enorm.

Hast Du Zahlen? Jeder sagt da was anderes. Werte zwischen 50-200 MB machen die Runde.

[v2afrank]

Bei mir startet er mit 25MByte
Nach Add 1000 komme ich auf 36.
Nach dem ersten runterscrollen bin ich bei 240MByte
Nach dem erneuten hochscrollen bin ich auf 244 MByte. Ich habe allerdings noch nicht das Update von XE2 installiert. Das muss ich mir erst noch am Wochenende runterladen

[Union]

Das Update1 ändert leider nix. Übrigens: je langsamer man scrollt desto höher der Speicherbedarf...

[bernau]

Zitat:

Zitat von Union (Beitrag 1127612)

Zitat:

Ja kann ich bestätigen. Der Speicherverbrauch steigt enorm.

Hast Du Zahlen? Jeder sagt da was anderes. Werte zwischen 50-200 MB machen die Runde.

Start: 18MB
+1000 Items: 35MB
Eine Seite Scrollen: +1,5MB
Liste ganz runtergeblättert: 130MB
Liste wieder hochblättern: 160MB

Das Blättern mit der Pfeiltaste verursacht übrigens eine CPU auslaszung von 40%

[Union]

Ist das 64 bit?

[bernau]

Ne. 32Bit-Debug

[v2afrank]

Ich habe jetzt auch gerade mal 64 Bit getestet
Start:19,564
+1000:36,952
unten:310,148
oben:312,692

[Union]

Jetzt hab ich es mal auf aktueller Business-Hardware getestet. 16 Kerne, Win 64-Bit, 24GB Ram. ABER: Standard VGA. Es wird unbedienbar langsam. So ein F*, meine Kunden sind keine Powergamer wo FMX sich auf einer Monster-GPU breitmachen kann. Die stellen sich immer die billigsten Kisten hin. Welche realitätsferne Dachplatte hat sich das bloss ausgedacht.

[bernau]

Ist mir auch aufgefalen. In der Scrollbox zu Blättern macht nicht wirklick spaß. Das bei einem handelsüblichen Laptop.

[Elvis]

Zitat:

Zitat von Union (Beitrag 1127720)

Jetzt hab ich es mal auf aktueller Business-Hardware getestet. 16 Kerne, Win 64-Bit, 24GB Ram. ABER: Standard VGA. Es wird unbedienbar langsam. So ein F*, meine Kunden sind keine Powergamer wo FMX sich auf einer Monster-GPU breitmachen kann. Die stellen sich immer die billigsten Kisten hin. Welche realitätsferne Dachplatte hat sich das bloss ausgedacht.

Wie würde das bei den immer mehr in Mode kommenden Citrix Terminals aussehen?
Sind denn FMX-Apps dafür überhaupt zu gebrauchen? Gerade in der Business-Welt will man ja weg von stromfressenden Desktops und hin zu kleinen Terminals. Aber die Terminal Sessions werden wohl kaum alle auf die eine Grafik-Karte im Server zugreifen können?

[Union]

Ich würde ja akzeptieren, dass dies bei grafisch aufwendigen (evzl. sogar 3D) so ist. Aber doch nicht eine normale Eingabemaske, die dann 200 MB Speicher frisst, hüben wie drüben nicht OS-Like aussieht und dann noch unbedienbar langsam ist.

[Medium]

Tja, das ist eben die Sache mit "sinnvoll" versus "an Otto-Normalo verkaufbar". Leider allzu gegenwärtig in der heutigen IT-Welt, und jetzt auch bei Embacodeborlando. Nicht, dass ich prinzipiell etwas gegen neue Techniken und UI-Paradigmen habe (im Gegenteil), aber so insgesamt scheint man einfach das Augenmaß für Verhältnismäßigkeit zwischen "gut aussehen" und Funktion verloren zu haben. Sowohl beim Entwickler als auch beim User. Bei ersterem kommt zudem die Nachlässigkeit, die "wir ham's ja" erzeugt, hinzu. That's how it is these days. /cheer