Autor Beitrag
motion
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 295

XP, Linux
D7 Prof
BeitragVerfasst: Sa 06.01.07 22:49 
In der Auftragsaufabwicklung verwende ich in einer Scrollbox eine dynamisch erzeugte Anzahl von verschiedenen Frames zur Darstellung der Auftragspositionen.
Funktioniert ausgezeichnet.
Allerdings stelle ich bei größerer Anzahl Positionen erhebliche Laufzeiten fest.
Beispiel:
Alles bis 100 Positionen fühlt sich schnell an.
Darüber hinaus kommt es zu immer deutlich spürbareren Laufzeiten bei der Erzeugung.
Mit Prodelphi habe ich die Sache mal untersucht und TFrame.Create verschlingt die ganze Laufzeit.
Gemessen z.B. mit
306 Positionen: 3,8sec.
612 Positionen: 10,5Sec.

Also eine überproportionale Zunahme der Laufzeit.
Natürlich beinhalten die Frames auch z.B. TEdit Componenten, die ebenfalls erzeugt werden (mit der Erzeugung des Frames automatisch).
Auch deren Erzeugungszeit steigt überproprotional an:
306 Pos., 1954 Aufrufe, 0,87Sec.
612 Pos., 3790 Aufrufe, 3,23Sec.

Hat jemand schon mal Erfahrungen gemacht mit der Erzeugung einer großen Anzahl Controls zur Laufzeit und was man dabei beachten/vermeiden sollte?
motion Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 295

XP, Linux
D7 Prof
BeitragVerfasst: So 07.01.07 00:21 
Ich habe gerade mal etwas weiter geforscht und ein kleines Testprojekt aufgesetzt:
In der Tat nimmt die Laufzeit für .create exponentiell zu.
Die Verwaltung der einzelnen Objekte nimmt immer mehr Zeit in Anspruch (z.B. Prüfung auf doppelte .name Eigenschaften etc.).

Leere TFrames lassen sich selbst sehr schnell erzeugen
Anzahl;durschn.Laufzeit pro TFrame.create;GesamtZeit
300 ;49,1µs;14,7ms
600 ;65,3µs;39,2ms
1200;105µs;126,8ms
2400;213µs;512ms

Nimmt man ein komplexeres Control, wie z.B. TMy_Edit (ein eigene Ableitung einer TMS Edit Komponente, welche wiederung von TEdit abgeleitet ist [naja, da sind noch mehr Vererbungen drin]), so wird das .create sehr schnell sehr viel komplexer (d.h. mehr Properties zu intialisieren, weitere .creates für eingebundere Objekte etc.).

Also bleibt da schon meine Erkenntnis:
*die Daten müssen in einfacheren Datentypen gespeichert werden (also einfache, eigene Objekttypen für die einzelnen Anzeigedaten der Auftragsabwicklung);
*keine komplexen Frames mit Controls drin zur Datenspeicherung und Editierung
*Anzeige auf dem Bildschirm mit Editierung,Scrollen etc. selbst zu Fuß programmieren (öhhh, habe ich da einen Bock drauf .... :-()

Mit der Scrollbox und den Frames drin, darin die einzelnen Controls, war es wunderbar einfach. Aber die Performance-Strafe ist schon zu spüren.
Nimmt man diese große Anzahl an Controls, so wird das System insgesamt schon sehr zäh (Refresh wird beim schnellen Wechseln des Focus per Tastatur langsam und wird erst wieder ausgeführt, wenn man eine Pause macht). Außerdem verbrät Windows dann ca. 40% CPU Zeit, auch wenn der PC überhaupt nicht angefasst wird. Ich vermute weil die ganzen Windows-Messages einmal durch alle Controls geschleust werden müssen.

Zum Glück ist das momentan kein akutes Problem, so dass ich das Redesign wohl in die Zukunft verschieben kann.
FastMM habe ich schon drin, so das ich momentan keine Idee habe, wie ich noch etwas mehr Performance auf die schnelle Rauskitzeln kann.