Warnung vor massivem Einsatz von Generics in Delphi

[DevidEspenschied]

Hallo WladiD,

insgesamt hast Du recht, angesichts der Architektur von Generics im Delphi-Compiler (und der Kernentscheidung, sie zu einem Kompilierungszeit-Tool ohne Laufzeitunterstützung zu machen) verursachen sie eine erhebliche Code-Aufblähung. Wir haben uns mit einigen Optimierungen befasst, und es gibt Raum für Verbesserungen bei der Kompilierungszeit und der Speichernutzung, aber solange wir nicht das gesamte System neu gestalten, werden die Verbesserungen in das aktuelle Modell fallen.

Entwicklern steht eine sehr wichtige Lösung, ein Workaround oder ein Hack zur Verfügung: die wiederholte Deklaration für dieselbe generische Typinstanz vermeiden. Zur Verdeutlichung: Ein generischer Typ ist TList<T>, eine generische Typinstanz ist TList<Integer>. Wenn man TList<Integer> in Unit A und Unit B hat, dann hat man zwei Typen, wobei alle Methoden in jede der beiden (oder 200) Units kopiert werden. Wenn man die Unit C erstellt, TList<Integer> dort einfügt, ihr einen bestimmten Typnamen gibt und diese Unit und diesen Typ verwendet, greift das Ganze auf die allgemeine Typverwendung zurück. Der Unterschied ist meines Wissens nach sehr signifikant und wir wissen, dass es bei vorhandenem Code etwas mühsam ist...

[Der schöne Günther]

Vielen Dank, das ganze Thema ist sehr anschaulich und hilfreich 👍

In meinem Fall bin ich mir unsicher abzuschätzen, ob das ganze in unserer Codebasis überhaupt schon ein nennenswertes Problem ist, oder in wie ferner Zukunft es problematisch werden könnte.

Ich kann mich erinnern, dass es ein Tool gab, das DCU-Dateien analysiert und darüber eine Aussage treffen konnte. Hat jemand den Namen noch parat?

[Redeemer]

Wirkt sich das Aufblähen der DCUs eigentlich auch auf die Größe der EXE aus?

[jaenicke]

Zitat:

Zitat von Redeemer (Beitrag 1544379)

Wirkt sich das Aufblähen der DCUs eigentlich auch auf die Größe der EXE aus?

Nein, das ist der Punkt, um den es geht. Der Linker wirft die doppelten Codeteile heraus und ersetzt diese durch Referenzen auf das erste Vorkommen des generischen Typs mit den passenden generischen Typparametern.

Wenn man nun sehr viele solcher Typen in den einzelnen Units hat, ist der Aufwand des Ersetzens sehr hoch. Und da die nötigen Informationen im Speicher benötigt werden, wird dafür viel Arbeitsspeicher benötigt.

[freimatz]

Habe ich es dann richtig verstanden? Statt

Delphi-Quellcode:

TCountList = TList<Integer>;
TWidthList = TList<Integer>;
TLengthList = TList<Integer>;

Wäre es dann also besser es so zu machen?

Delphi-Quellcode:

TIntegerList = TList<Integer>;

TCountList = type TIntegerList;
TWidthList = type TIntegerList;
TLengthList = type TIntegerList;

[himitsu]

Es wäre auch viel zu einfach, die jeweiligen TypBezeichner im Generic schnell zum voll-qualifizierten Namen auflösen und diesen Namen dann in iner kleinen Liste zu speichern und bei der Generic-Deklaration anfangs in der Liste zu schauen,
anstatt erstmal zu kompilieren und dann in einer fetten Liste nach dem Resultat zu suchen. :roll::stupid:

[Rolf Frei]

Hat Delphi 12.2 nicht einen 64 Bit Compiler und Linker erhalten, der aber idiotischerweise nur in der Enterprise+ Version enthalten ist. Ist damit das Memory Problem nicht gelöst? Oder mache ich hier ein Durcheinander?

Zitat:

Delphi 64-bit Compilers

RAD Studio version 12.2 Enterprise and Architect versions include 64-bit versions of the Delphi compilers. The new feature is referred to as 64-bit tools architecture. Using 64-bit tools allows users to have a larger memory space available to the compiler and, therefore, the ability to compile larger applications without running into memory issues.

The following are the new 64-bit tools:

Delphi Windows 32-bit target compiler
Delphi Windows 64-bit target compiler

Using the external MSBuild to compile, in the Delphi compiler configuration in the RAD Studio IDE Project Options dialog box, specify the version of the tools (including the command line compilers) to use in the “Preferred tool architecture” field.

Find the Delphi Windows command line compilers, dcc32.exe and dcc64.exe, in the RAD Studio installation bin64 folder (C:\Program Files (x86)\Embarcadero\Studio\23.0\bin64 by default), the. Similar executables still exist in the product bin folder, the command line compiler 32-bit versions.

[himitsu]

Jupp, es gibt einen zweiten Win64-Compiler und nur in Enterprise (nicht CE und Professional), und auch nur für C++Builder (glaub i) ... auch wenn dennoch in den Settings überall "Win64 (modern)" zu finden ist ... schon länger, selbst wenn ausschließlich Delphi (nicht RAD Studio) installiert ist. :freak:

[Rolf Frei]

Wir haben hier ja zum Einen was wir für eine Output gegenerieren wollen und zum Anderen eben neu, wie der Compiler/Linker selber compiliert ist, also 32 Bit oder bei den neuen mit 64 Bit. Bisher war wohl der Compiler und Linker 32 Bit Programme inkl 4GB Memorybegerenzung. Die neuen 64 Bit Compiler sind in nativem 64 Bit compiliert und haben damit diese Memorygrenze nicht mehr. Dass da die Doku von Win64 etc. redet ist ja so schon korrekt, denn auch bisher konnte man ja selber 32 + 64 bit Programme erzeugen.

[himitsu]

https://www.embarcadero.com/de/produ...w-in-12-athens
https://docwiki.embarcadero.com/RADS...on_Development
https://en.delphipraxis.net/topic/11...in-delphi-121/