Warnung vor massivem Einsatz von Generics in Delphi

[WladiD]

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

Es ist zumindest eine Zwischenlösung, wenn das jeweilge Projekt wieder kompiliert werden kann, bei der die 32-bittige dcc32.exe sonst scheitert.

Das Problem dabei ist jedoch, dass ein entsprechend großes Projekt eine große RSM-Datei erzeugt. Diese wird auch zum lokalen Debuggen benötigt, wenn man das Projekt über MS-Build erzeugt. Das heißt, im ungünstigen Fall kann man vielleicht wieder kompilieren, aber nicht mehr debuggen, weil die IDE in ihr Speicherlimit reinläuft. Bei uns ist gleich beim ersten Debug-Versuch die bds.exe bei über 2GB. Nach einigen weiteren Debug-Versuchen kommt die geliebte EOutOfMemory...

[himitsu]

Jupp, alles, was nicht 32 Bit ist, muß ja remotegedebuggt werden, da die IDE und der InlineDebugger ja nur 32 Bit sind.

Vielleicht, wenn in 25 Jahren dann wieder, wenn die IDE auch 64 Bit ist.


Wobei es dennoch irgendwie komisch ist, dass die "gleichen" Debuginfos jeweils so unterschiedlich groß sind.

Dass eine billige ZIP-Komprimierung aber so extrem viel einspart, lässt einen irgendwie denken, dass da viel "nichts" drin steckt.

[TurboMagic]

Naja, ich glaube schon, dass wir viel früher als in 25 Jahren eine 64 Bit IDE sehen werden.
Nur wäre es natürlich klasse, wenn man den Speicherbedarf auch ohne Wechsel auf 64 Bit senken
könnte.

Die Methode "viele Hardware Ressourcen auf ein Problem zu schmeißen" ist ja auch nicht gerade
umweltfreundlich und kann auch an ihre Grenzen stoßen...

[jaenicke]

Zitat von TurboMagic:

Naja, ich glaube schon, dass wir viel früher als in 25 Jahren eine 64 Bit IDE sehen werden.

Was Marco Cantù auf der EKON gesagt hat, war so ungefähr:
Sie haben eine lauffähige 64-Bit IDE, die aber noch nicht stabil genug ist. Sie werden diese in den nächsten Monaten so weit haben, dass man damit zumindest testen kann. Und als erstes müssen ja z.B. die Komponentenhersteller ran. Von daher gehe ich mal davon aus, dass eine wirklich relativ normal für alle nutzbare 64-Bit IDE Richtung 2026 kommen könnte. Und dazwischen irgendwann eine Beta für alle.
Wie gesagt: Das ist meine Erinnerung und Interpretation dessen, was ich dort gehört habe.

Zitat von TurboMagic:

Nur wäre es natürlich klasse, wenn man den Speicherbedarf auch ohne Wechsel auf 64 Bit senken
könnte.

Da wurde ja auch schon dran gearbeitet, aber es sind halt auch sehr viele Informationen. Und wenn ich sehe, dass Visual Studio für ein echt sehr kleines Projekt schon 1,5 GiB Arbeitsspeicher benötigt und zum Kompilieren noch einmal 200 MiB dazu kommen, dann finde ich nicht, dass Delphi besonders viel braucht. Der Unterschied ist halt die plattformbedingte Beschränkung des Arbeitsspeichers bei Delphi.

Zitat von TurboMagic:

Die Methode "viele Hardware Ressourcen auf ein Problem zu schmeißen" ist ja auch nicht gerade
umweltfreundlich und kann auch an ihre Grenzen stoßen...

Bei den heutigen PCs, insbesondere Entwicklermaschinen, halte ich es aber für sehr sinnvoll, möglichst viel im Arbeitsspeicher für schnellen Zugriff zu halten.

[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);

[WladiD]

Zitat von DevidEspenschied:

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...

Hallo David,

den Workaround über einen Typ-Alias für generische Interfaces hat ein Kollege schon vor einem Jahr probiert. Die Erkenntnis war damals, dass es nichts gebracht hat. Ich habe auch ein ähnliches Experiment in einem isolierten Test-Projekt durchgeführt und bin zum gleichen Ergebnis gekommen, aber ich muss zugeben, dass meine primäre Metrik die Größe der resultierenden Exe war und nicht die Größe der einzelnen DCUs. Dies ist wiederum auf die gute Arbeit des Linkers zurückzuführen.

Gestern hat ein Kollege, auf ihren Post hin, wieder ein Testprojekt gebaut und dort kann man tatsächlich feststellen, dass ein Alias IListString = IList<String> etwas gebracht hat, wenn die zugehörige Factory (TCollections.CreateList<String>) nicht in der konsumierenden Unit vorkommt, sondern über eine eigene Factory-Funktion in einer dedizierten Unit bezogen wird.

Das ist schon mal eine interessante neue Erkenntnis.

Da ich gerade dabei bin...
Wie ist Ihre Aussage bezüglich einer 64-Bit-IDE?
Wann gibt es ungefähr die erste Beta?

[freimatz]

Zitat von WladiD:

Da ich gerade dabei bin...
Wie ist Ihre Aussage bezüglich einer 64-Bit-IDE?
Wann gibt es ungefähr die erste Beta?

Bitte nicht, sondern separat. Das Thema Generics ist schon gross genug.

[MyRealName]

Zitat von freimatz:

Zitat von WladiD:

Da ich gerade dabei bin...
Wie ist Ihre Aussage bezüglich einer 64-Bit-IDE?
Wann gibt es ungefähr die erste Beta?

Bitte nicht, sondern separat. Das Thema Generics ist schon gross genug.

Ein Pun der feinsten Klasse, I commend you, good sir!

[freimatz]

Zitat von himitsu:

...
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);

Äh - na klar geht auch. Vermutlich sogar etwas schöner.
Und hilft das?