Generics / Speicherprobleme in der IDE

[ventiseis]

Hallo,

da bei uns die IDE regelmäßig wg. Speicherproblemen abstürzt, bin ich mal auf die Suche gegangen, warum die DCUs eines Moduls so groß werden.

Hauptgrund scheint zu sein, dass durch die Generics unser Objektmodell zu umfangreich wird (größte DCU: 14MB). Nach einer Analyse mit MapFileStats (http://www.delphitools.info/other-tools/mapfilestats/) wird der meiste Platz offensichtlich dadurch verbraucht, dass generische Typen (z.B. Listen) immer wieder neu "kopiert" werden, obwohl die Implementierung für normale Objekte eigentlich identisch sein müsste.

Jetzt nun die Frage, gibt es irgendeine Möglichkeit / Strategie, dieses Dilemma zu umgehen? Sollte man wieder eigene Collectionklassen schreiben (oder für jeden Typ eine Ableitung von TCollection erzeugen)? Wie seid ihr mit dem Problem umgegangen?

Einerseits möchte man ja die Typsicherheit von generischen Listen behalten, andererseits nützt die einem auch nix mehr, wenn man nach jedem Compilieren Delphi neu starten muss.

PS: Die üblichen Einstellmöglichkeiten (Projektoptionen) haben wir schon durchprobiert. Und ja, wir verwenden RTTI im Objektmodell. Und wir kompilieren Debug-Infos mit ein, damit im Fehlerfall Zeilennummern mit ausgegeben werden. Laufzeitpackages sind auch aktiv, allerdings nur für die gängigen Delphi-Packages (vcl,rtl, ..).

[Uwe Raabe]

Die aktuelle Implementierung der Generic ist in Bezug auf den Speicherverbrauch sicher noch verbesserungsfähig. Eine geschicktere Implementierung für Collections findest du allerdings im Spring4D-Framework.

[quaero]

Mehrfach vorkommende Typen und Typen, die als Parameter genutzt werden, nur einmal pro Projekt definieren und dann diesen Typ verwenden:

Delphi-Quellcode:

TMyIntList = TList<Integer>;

TMeinObject = class
  FIrgendeineListe: TMyIntList
  procedure tueWas(const liste: TMyIntList);
...

Dann muss dieser Typ nur einmal ins Objektmodell.

[ventiseis]

Zitat von quaero:

Mehrfach vorkommende Typen und Typen, die als Parameter genutzt werden, nur einmal pro Projekt definieren und dann diesen Typ verwenden.

Machen wir manchmal, aber nur um die Lesbarkeit des Quelltextes zu verbessern.

Beispiel:
TDataCache = TObjectDictionary<string, TList<TData>>

[Stevie]

Zitat von Uwe Raabe:

Die aktuelle Implementierung der Generic ist in Bezug auf den Speicherverbrauch sicher noch verbesserungsfähig. Eine geschicktere Implementierung für Collections findest du allerdings im Spring4D-Framework.

Jaaa, allerdings erst ab der noch zu releasenden 1.2 oder dem aktuellen develop Stand.

Hintergrund Info, wie das gelingt:
Da die Spring4D Collection Types alle über Interfaces geregelt sind, kann man hinter eine IList<TKunde> "einfach" eine TObjectList<TObject> hängen. Das geht aber nunmal bei puren klassenbasierten generischen Listentypen nicht (und nein, auch die verzweifelten Versuche in XE8 ändern da nix dran).

Zitat von quaero:

Mehrfach vorkommende Typen und Typen, die als Parameter genutzt werden, nur einmal pro Projekt definieren und dann diesen Typ verwenden:

Delphi-Quellcode:

TMyIntList = TList<Integer>;

TMeinObject = class
  FIrgendeineListe: TMyIntList
  procedure tueWas(const liste: TMyIntList);
...

Dann muss dieser Typ nur einmal ins Objektmodell.

Dass dieser Irrglaube immer noch herumgeistert... Nein, nein, nein. Der Compiler bekommt das schon mindestens sein XE (glaube sogar schon mit Delphi 2010) hin, dass er nur einmal eine TList<Integer> baut, egal an wie vielen Stellen ich sie einsetze. Allerdings bekommt er es nicht hin, dasselbe zu tun, wenn ich eine TList<TKunde>, TList<TRechnung>, TList<TBestellung> habe, weil der generische Typparameter immer ein anderer ist, auch wenn der generierte binärcode bis auf das letzte Byte identisch ist.

[Der schöne Günther]

Das macht den erzeugten Code größer, klar. Aber das soll eine Ursache für das "Out of Memory"-Problem in der IDE sein?

[Stevie]

Zitat von Der schöne Günther:

Das macht den erzeugten Code größer, klar. Aber das soll eine Ursache für das "Out of Memory"-Problem in der IDE sein?

Soweit ich weiß, ist das eine Mitursache, da diverse Dinge in der IDE gecached werden, und je mehr da gecached wird, desto mehr Speicher.
Aber genau kann das glaub ich, Andreas beantworten.

[ventiseis]

Zitat von Der schöne Günther:

Das macht den erzeugten Code größer, klar. Aber das soll eine Ursache für das "Out of Memory"-Problem in der IDE sein?

Ich gehe schon davon aus, dass dies bei unseren Projekten der Fall ist. In älteren Projekten (mit nicht-generischen Objektmodellen) tritt die IDE-Problematik viel seltener auf.

[ventiseis]

Zitat von Stevie:

Da die Spring4D Collection Types alle über Interfaces geregelt sind, kann man hinter eine IList<TKunde> "einfach" eine TObjectList<TObject> hängen. Das geht aber nunmal bei puren klassenbasierten generischen Listentypen nicht (und nein, auch die verzweifelten Versuche in XE8 ändern da nix dran).

Danke für den Tipp! Vielleicht lässt sich hier eine "Idee" übernehmen.

[jbg]

Zitat:

Zitat von Stevie:

Dann muss dieser Typ nur einmal ins Objektmodell.

Dass dieser Irrglaube immer noch herumgeistert...

Jain. Der Compiler instanziert den Generic für jede DCU-Datei wo er deklariert wird. Erst der Linker vereint dann die Generics mit den selben Typen-Parametern (mit einem sehr langsamen Algorithmus => CompilerSpeedPack enthält einen Patch, damit Spring4D um welten schneller kompiliert).

Speicherverbrauch
Der ErrorInsight/Refactoring Parser trägt hier die Hauptschuld. Dieser verbraucht nämlich für DCU Dateien den doppelten Speicherplatz. Er lädt über den Compiler die DCU Dateien von denen er keine PAS Dateien findet (z.B. System.dcu, Controls.dcu, Forms.dcu, ...) und überträgt dann Teile, welche er gerade braucht, in seine eigene .NET Klassenstruktur. Somit hat man die DCU und die .NET Objekte zu den Daten aus der DCU im Speicher.
Trifft der Parser auf einen Generic (DCU oder PAS), dann geht der Speicher Verbrauch erst so richtig los, denn er instanziert den Generic und kopiert dabei sämtliche Typen. Wenn dann auch noch dank Garbage Collector sich niemand Gedanken macht, wo denn diese Generics-.NET Objekte noch referenziert werden, dann bleiben sie eben bis zum Schließen des Projekts im Speicher.

Dass der Compiler durch die ganzen Ändernung und die Generics natürlich auch mehr Speicher für seine Daten braucht, tut dem ganzen natürlich auch nicht wirklich gut.

Und dann kommt noch das Problem dazu, dass DCU Dateien, die von mehreren Projekten innerhalb einer Projektgruppe genutzt werden, nicht einmal, sondern für jedes einzelne Projekt im Speicher liegen. Hat man also 10 Projekte in einer Projektgruppe und kompiliert diese, dann sind da auch 10 System.dcu, SysUtils.dcu usw. im Speicher. Da hatte ich auch schon ein paar Ideen wie ich die vereinen kann, aber leider schreibt der Compiler in den Speicherbereich während des kompilierens Daten rein, womit man den DCU-Block ala XMS-Speicher under DOS austauschen müsste. Die notwendigen Swap-Codestellen lassen sich aber ohne Compiler-Quellcode recht schlecht alle aufspüren. Also bliebe nur ein empierisches Vorgehen mittels VirtualProtect(READONLY)+VectoredExecptionHandler. Dann müssten aber auch alle möglichen Codepfade durchlaufen werden, welche ich sicherlich nicht alle finden würde.