Warnung vor massivem Einsatz von Generics in Delphi

[WladiD]

Zitat von TigerLilly:

@WladiD: Ist das mit der Spring4D v2 immer noch so? Ich habe da das im Kopf (siehe weiter unten nach den Benchmarks:
https://delphisorcery.blogspot.com/2...lution-of.html

Spring4D v2 hat uns sehr beim Reduzieren des Code-Bloats geholfen. Unsere Exe ist beim Wechsel von Spring4D v1.x auf v2 von 170 auf ca. 110 MB geschrumpft, auch der RAM-Verbrauch des Compilers/Linkers sank dadurch deutlich. Doch unser Code wächst weiter und so kommen stetig neue generische Typen dazu und dies führt wieder zu den Problemen die ich Eingangs ausgeführt habe.

[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 von Redeemer:

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.

[Stevie]

Zitat von jaenicke:

Zitat von Redeemer:

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.

Leider funktioniert das bei "normalen" generics nicht so wirklich gut, wenn ich TList<TApfel> und TList<TBirne> habe (beides sind Klassen), gibt es den code für TList<T> 2mal in der Binary (einmal für TApfel und einmal für TBirne) obwohl er komplett identisch ist. Bei Spring4d foldet er das intern auf die implementierung von TList<TObject>. Das geht, da die collections Interface basiert sind. IList<TApfel> und IList<TBirne> erzeugen nur wenig Binärcode und dahinter hängt dann jeweils dieselbe implementierung (mehr oder weniger, gibt noch einige Details, die hier aber irrelevant sind).

Schwierig wird es dann bei assoziativen Collections, also solchen, wo man 2 generische Parameter hat, da sich die Kombinationen dann multiplizieren. Das kann man inzwischen sehr gut sehen, wenn man eine FMX Anwendung oder eine Anwendung mit einer Drittanbieter Bibliothek verwendet, die auch ausgiebig Gebrauch von Generics machen, z.B. DevExpress. Da hat man dann mitunter einen zweistelligen Prozentanteil an Binärgröße nur mit Zeugs aus System.Generics.Collections verbraten.

[Stevie]

Zitat von DevidEspenschied:

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

Leider falsch.

Zitat von 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;

Kompiliert leider nicht - E2574 - siehe auch https://quality.embarcadero.com/browse/RSP-27505

Zum allgemeinen Thema:
Hab ich schon 2014 bzw 2017 gesagt - siehe:
https://delphisorcery.blogspot.com/2...-annoying.html
https://quality.embarcadero.com/browse/RSP-18080

Zitat von WladiD:

Ich bin ein Fan von Generics, aber unter diesen Umständen kann ich vom weiträumigen Einsatz in großen Delphi-Projekten nur abraten!

Zur konkreten Problematik bzgl Spring4D 2.0 - es mag an den speziellen Typen liegen die ihr in den generischen Parametern nutzt, speziell wenn das sehr viele verschiedene record Typen sind, dann gibt es leider keine Möglichkeit, die Code folding Techniken anzuwenden, die ich in 2.0 eingebaut habe, aber ggf andere Möglichkeiten.

Zitat von WladiD:

generische Typen, entweder aus der internen Basisbibliothek oder aus dem Spring-Framework abzuleiten und zu verwenden

Ich weiß nicht, in welchem Maße ihr von den Klassen aus Spring4D ableitet, aber je nachdem wie ihr das macht und diese dann verwendet, kann das erst das Problem verursachen, was ich mit 2.0 massiv reduziert habe.

Schick mir gern eine pm oder email, wenn ihr diesbezüglich Hilfe von mir benötigt.

[himitsu]

Zitat:

Delphi-Quellcode:

TIntegerList = TList<Integer>;

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

Da das Klassen sind, kann man doch auch noch anders ableiten.

Delphi-Quellcode:

TIntegerList = TList<Integer>;

TCountList = class(TIntegerList);
TWidthList = class(TIntegerList);
TLengthList = class(TIntegerList);