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.

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.

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

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

Zitat von jfheins:

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

Zitat von Sir Rufo:

Zitat von jfheins:

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

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.

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

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:

markieren

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.