Delphi-Controls sind bei großen Mengen langsam

[luisk]

Feststellung:
Delphi-Controls sind bei großen Mengen langsam.
Das sollte man dem Stand der Technik anpassen.
Selbst bei CSS in Webbrowsern kann man sehen, dass es schneller geht.

[Daniel]

Mal Butter bei Fische.
Welche Controls und wie viele Daten? Welche Antwortzeiten werden als langsam erachtet, welche als schnell? Wir können nicht im leeren Raum diskutieren - wenn wir hier eine ernsthafte Diskussion führen wollen, dann brauchen wir eine gemeinsame konkrete Ausgangslage.

[Sir Rufo]

Er sprach von 3000 Sublayouts mit ein paar Controls in einer Scrollbox.

Den gleichen Effekt habe ich aber unter C# Windows.Forms auch. Ohne Virtualisierung geht es nicht (schneller) und die gewrappten Windows-Controls können das nicht (mehr ist so ein Edit, Label, Button unter VCL/Windows.Forms nämlich nicht).

[jfheins]

Windows allgemein wird langsam, wenn man zu viele Fenster öffnet. Der Delphi Overhead kommt da natürlich noch drauf, aber swo irre viel wird das jetzt auch nicht sein.
Zum Beispiel gibt es das Limit mit 10000 Fenstern pro Prozess, darüber winkt Windows mit dem Zaunpfahl, dass etwas nicht stimmt ^^

Wenn man wirklich so irre viel Zeug anzeigen will, dann darf man nicht zu allem ein Handle generieren. Vll. ein paar Links: https://blogs.msdn.microsoft.com/old...11-00/?p=36473 https://blogs.msdn.microsoft.com/old...15-00/?p=36183

Ich müsste mal gucken, wie sich eine WPF Listbox mit 3000 Elementen verhält .... WPF ist ja eigentlich nicht für extreme Performance bekannt ...

[Sir Rufo]

Zitat:

Zitat von jfheins (Beitrag 1341084)

Ich müsste mal gucken, wie sich eine WPF Listbox mit 3000 Elementen verhält .... WPF ist ja eigentlich nicht für extreme Performance bekannt ...

pornoschnell ... wenn man mit der Virtualisierung arbeitet :stupid:

[Bernhard Geyer]

Zur info für Andere: Vordiskussionen erfolgten in anderen Thread: "wann gibt es in Delphi einen NAMESPACE wie in c#"


Zum Problem:
Ich vermute (Beispielprogramm steht noch aus - habe ich schon zwei mal angefragt) das der Programmiertechnische Ansatz falsch ist.

Wenn ich eine Datenmenge von tausenden Datensätzen und für jeden Datensatz z.B. 3 Edits, 2 Images und 1 Memo benötige wird Delphi (bzw. Windows) die Grätsche Machen wenn ich versuche tausende diese Controls auf einer Scrollbox anzulegen.


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 wäre dann das Gegenstück zum Paging bei HTML-Lösungen.

Macht man das nicht macht Delphi/Windows dir grätsche. Genauso macht der Browser ebenfalls dir grätsche wenn man diese 1000 Bilder in einem HTML-Dokument zum Client bringt (Von der höheren Renderingzeit abgesehen).

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1341085)

Zitat:

Zitat von jfheins (Beitrag 1341084)

Ich müsste mal gucken, wie sich eine WPF Listbox mit 3000 Elementen verhält .... WPF ist ja eigentlich nicht für extreme Performance bekannt ...

pornoschnell ... wenn man mit der Virtualisierung arbeitet :stupid:

Und genau diese Virtualisierung macht z. B. das Beispiel von Mobile auch. 20 Datensätze werden angezeigt und der Rest gar nicht aufbereitet und zum Client übertragen.
Aber diese Virtualisierung bekommt man auch in Delphi sehr schnell hin bzw. wird ja mit dem TDBCtrlGrid direkt "codeless" unterstützt.

[Sir Rufo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1341089)

Zitat:

Zitat von Sir Rufo (Beitrag 1341085)

Zitat:

Zitat von jfheins (Beitrag 1341084)

Ich müsste mal gucken, wie sich eine WPF Listbox mit 3000 Elementen verhält .... WPF ist ja eigentlich nicht für extreme Performance bekannt ...

pornoschnell ... wenn man mit der Virtualisierung arbeitet :stupid:

Und genau diese Virtualisierung macht z. B. das Beispiel von Mobile auch. 20 Datensätze werden angezeigt und der Rest gar nicht aufbereitet und zum Client übertragen.

Wenn ich jetzt die Haarspalter-Axt heraushole dann ist das auf der Mobile Seite Paging :stupid:

[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

[Bernhard Geyer]

Zitat:

Zitat von Sir Rufo (Beitrag 1341092)

Wenn ich jetzt die Haarspalter-Axt heraushole dann ist das auf der Mobile Seite Paging :stupid:

Stimmt natürlich. Ist ein anderer Lösungsansatz um das Problem zu lösen.

[luisk]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1341088)

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:

Zitat von jaenicke (Beitrag 1341095)

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::thumb:
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 :wink:)

[stahli]

Schön, dass es sachlich zugeht. :thumb:

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:

Zitat von luisk (Beitrag 1341104)

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:

Zitat von luisk (Beitrag 1341104)

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:

Zitat von luisk (Beitrag 1341104)

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:

Zitat von EWeiss (Beitrag 1341120)

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:

Zitat von EWeiss (Beitrag 1341122)

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:

Zitat von EWeiss (Beitrag 1341122)

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

Implementierungszeit >> 1 Mannmonat.

Zitat:

Zitat von EWeiss (Beitrag 1341122)

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:

Zitat von EWeiss (Beitrag 1341122)

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:

Zitat von luisk (Beitrag 1341104)

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;

[luisk]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1341119)

Das Control heiß TDBCtrlGrid.

Ich habe Delphi 10 Seatle, Professional with mobile.
Da ist diese Komponente nicht vorhanden.

Ich bau mir jetzt alles über TGrid zusammen. Da stimmt die Performance.
TGrid (FMX) hatte ich glatt übersehen. Hatte nach TDrawGrid (VCL) gesucht.

[Bernhard Geyer]

Zitat:

Zitat von luisk (Beitrag 1341128)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1341119)

Das Control heiß TDBCtrlGrid.

Ich habe Delphi 10 Seatle, Professional with mobile.
Da ist diese Komponente nicht vorhanden.

http://docwiki.embarcadero.com/Libra...ds.TDBCtrlGrid
Ob es das auch unter FMX gibt weiß ich nicht.