Delphi-Controls sind bei großen Mengen langsam

[luisk]

Zitat von Bernhard Geyer:

Sinnvoll ist es wie es ja mittlerweile bei Delphi seit einigen Jahren gibt ein "Repeater-Control" zu haben, auf das ich diese Controls lege und dieses Control sorgt dafür das die aktuell angezeigten Datensätze auch in Edits/Images/... visualisiert werden.

Das sagt das Netz zu "Delphi repeater control":
https://www.devexpress.com/Support/C...etails/Q477685
https://www.google.de/webhp?sourceid...control+delphi

Hier Dein Quelltext:

Delphi-Quellcode:

for i:=1 to 5000 do begin
   l_Layout:=TLayout.create(scrollbox1);
   l_Layout.Parent:=scrollbox1;
    :
    create_Content(l_Layout);
end;

Ich sage, sowas sollte ein modernes System können.
Dass das Problem bei den Windows-Handles liegt ist schon klar.

[luisk]

Zitat von jaenicke:

So viele Controls funktionieren nirgends gut, weder bei Java, noch bei C# noch bei Delphi. Und das liegt eben daran, dass das Problem nicht die Performance bei so vielen Controls ist, sondern das Konzept, das so viele Controls benötigt.

Wenn ich zum Beispiel für die Anzeige meines Periodensystems für jede Anzeige jeweils ein TLabel usw. verwendet hätte, wäre das auch bei weitem nicht so schnell. Und es würde auch schlechter aussehen.
Dort siehst du wie man so etwas zum Beispiel einfach selbst zeichnen kann:
http://www.delphipraxis.net/132375-p...-beta-6-a.html

Tolles Beispiel:
http://www.delphipraxis.net/attachme...odmainform.png
Sowas sollte man mit Standard-Controls aufbauen können.
Wenn es nicht geht, sehe ich einen gravierenden Designfehler in den Komponenten.
(meine Meinung. Jeder kann ja seine eigene Meinung haben )

[stahli]

Schön, dass es sachlich zugeht.

Das Thema an sich finde ich schon interessant.
Ich hatte in der Richtung auch schon mal einen Thread: http://www.delphipraxis.net/175033-f...-schlecht.html

Dass die VCL mit tausenden Controls nicht umgehen kann, kann ich schon nachvollziehen.
Windows-Controls sind dafür halt nicht ausgelegt und das VCL-Konzept hat ja schon ein paar Jahre auf dem Buckel.

Von FMX hätte ich mir seinerzeit mehr erhofft.
Ok, man sollte keine 100.000 Controls erzeugen und zeichnen, aber ein paar hundert sollten machbar sein.
Große Datenmengen sollten automatisch virtualisiert werden, so dass man sich darum als Entwickler nicht kümmern muss.

Dass bei meinen Versuchen damals komplette existente Datenlisten in Listencontrols kopiert wurden hat mich sehr verwundert.
Klar kann man das umgehen, aber das bringt einen höheren Aufwand mit sich.

(Bei meinem kurzen Ausflug nach Winforms und WPF schien das aber dort auch nicht besser geregelt zu sein.)


Das war früher bei der BDE sehr gut gelöst. Man hat als Anfänger einfach eine Table an ein Grid gebunden und konnte in 1Mio Datensätzen flüssig scrollen. Ich will natürlich nicht die BDE zurück, aber das genannte Handling wäre schon erstrebenswert.

EDIT: Um gleich einzulenken, natürlich scrollt niemand durch 1Mio Datensätze, aber es mach schon einen Unterschied, ob ich als Entwickler mal eben eine große Tabelle an ein Grid binden kann oder ob die GUI oder das ganze Projekt dabei in die Knie geht.

[Bernhard Geyer]

Zitat von luisk:

Das sagt das Netz zu "Delphi repeater control":
https://www.devexpress.com/Support/C...etails/Q477685
https://www.google.de/webhp?sourceid...control+delphi

Das Control heiß TDBCtrlGrid.

Zitat von luisk:

Hier Dein Quelltext:

Delphi-Quellcode:

for i:=1 to 5000 do begin
   l_Layout:=TLayout.create(scrollbox1);
   l_Layout.Parent:=scrollbox1;
    :
    create_Content(l_Layout);
end;

Ich sage, sowas sollte ein modernes System können.

Kann es auch: TDBCtrlGrid.

Aber wenn du das obige 1:1 auf die Web/HTML-Lösung umsetzt wirst du da auch Probleme kommen.
Wir selbst kennen das primär beim IE der auch mit der letzten Version bei vielen HTML/CSS-Elementen teilweise sehr langsam wird.

Zitat von luisk:

Dass das Problem bei den Windows-Handles liegt ist schon klar.

Der Ansatz ist ja auch nicht sinnvoll.
Was sillst du mit 5000 erzeugten TLayout-Instanzen. Sichtbar sind wie viele davon?
Über eine Virtualisierungs-Ansatz reicht es 10 Instanzen zu haben und für die anderen nur "Platzhalter" in der Scrollbar damit die Position korrekt ist.
Und nur wenn die Scrollbar an der entsprechenden Position ist laden die Controls den entsprechenden Inhalt.

[EWeiss]

Bin mir nicht sicher ob es sinn macht Controls generell in der IDE zu limitieren.
Aber MS hat sich schon etwas dabei gedacht für die IDE in VB6 die Controls auf 256 zu beschränken.
Mehr geht halt nicht somit kam so eine Frage gar nicht erst auf.

Virtualisierung hingegen in WPF ist schon schnell.

gruss

[Bernhard Geyer]

Zitat von EWeiss:

Bin mir nicht sicher ob es sinn macht Controls generell in der IDE zu limitieren.
Aber MS hat sich schon etwas dabei gedacht für die IDE in VB6 die Controls auf 256 zu beschränken.
Mehr geht halt nicht somit kam so eine Frage gar nicht erst auf.

Da im Beispiel die Controls dynamisch erzeugt werden hilft eine solche Einschränkung nicht.
Und komplexere Anwendungen mit VB (nicht VB.NET) sind m.E. Fail by Design.

[EWeiss]

Zitat:

Und komplexere Anwendungen mit VB

Jemals schon versucht? Denke du redest von Hörensagen.
Ich meinerseits habe eine Komplexe Anwendung in VB6 geschrieben und verwende sie noch heute.

Wie definierst du Komplex?
Abhängig von den verwendeten (der menge an) Controls.

256 sind 256 es spielt dabei keine rolle ob dynamisch oder nicht. (VB6)
Und ja ich sehe es als sinnvoll an diese zu beschränken.

Ich denke bei einer Verwendung von mehr.. dann liegt ein Design Konzept, problem vor.

Zitat:

m.E. Fail by Design.

Sind bei mir Anwendungen (wenn auch nur als Beispiel) mit 5000 Scrollbars.

gruss

[Bernhard Geyer]

Zitat von EWeiss:

Zitat:

Und komplexere Anwendungen mit VB

Jemals schon versucht? Denke du redest von Hörensagen.

Hab schon mit diversen Systemen (u.a. Access-VB, VS mit MFC) zu tun gehabt.
Glücklicherweise nicht tiefergreifend mit VB direkt sondern ich konnte hier doch wieder ein vernünftige Lösung wie Delphi nehmen

Zitat von EWeiss:

Ich meinerseits habe eine Komplexe Anwendung in VB6 geschrieben und verwende sie noch heute.
Wie definierst du Komplex?

Implementierungszeit >> 1 Mannmonat.

Zitat von EWeiss:

256 sind 256 es spielt dabei keine rolle ob dynamisch oder nicht. (VB6)
Und ja ich sehe es als sinnvoll an diese zu beschränken.

Ich denke bei einer Verwendung von mehr.. dann liegt ein Design Konzept, problem vor.

Nicht unbedingt. Für viele Anwendungen würde diese Anzahl an Control den normalen Anwender überfordern.
Spezialanwendungen aber die z.B. über Großleindwände/Zig HD-Bildschirme laufen kann eine entsprechend Anzahl von Control nötig sein.
Hier 256 als harte Grenze zu haben wäre kontraproduktiv.

Zitat von EWeiss:

Zitat:

m.E. Fail by Design.

Sind bei mir Anwendungen (wenn auch nur als Beispiel) mit 5000 Scrollbars.

Das sicherlich auch.

[EWeiss]

Zitat:

ich konnte hier doch wieder ein vernünftige Lösung wie Delphi nehmen

Warum dann nicht direkt C++.
Delphi war dann wohl die 3 Wahl ? "Vernünftige" ist wohl relativ.

Zitat:

Hier 256 als harte Grenze zu haben wäre kontraproduktiv.

Dann sollte man sich aber über den langsamen Aufbau einer Anwendung nicht wundern.

Das wäre dann auch Kontraproduktiv..
Aber gut jedem seine Meinung.

gruss

[Bernhard Geyer]

Zitat von luisk:

Hier Dein Quelltext:

Wenn das dein Quellcode ist kannst du den Overhead des Eerzeugens und auf Parent-Setzen evtl. um ca. 90% beschleunigen wenn statt auf der Scrollbox alle Controls auf ein "Trägerpanel" erzeugt werden und diese dann der Scrollbox zugewiesen wird.

5000 Edits auf Scrollbox direkt erzeugen: 18,5 Sekunden
Verhindern neuzeichnen Srollbox mit WM_SETREDRAW: 10 Sekunden
Edits auf Trägerpanel erzeugen: 2,5 Sekunden

Das sind die Zeiten über Remote Desktop. Evtl. läuft das direkt schneller.

Meine "Business-Code" hierzu war:

Delphi-Quellcode:

  for i := 0 to 5000 do
  begin
    ctrl := TEdit.Create(ScrollBox1);
    ctrl.Parent:=scrollbox1;
    ctrl.Text := 'Herbert ' + i.ToString();
    ctrl.Top := i * 24;
    ctrl.Left := 16;
  end;