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.