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.