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.

[Stevie]

Zitat:

Zitat von Uwe Raabe (Beitrag 1298863)

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:

Zitat von quaero (Beitrag 1298924)

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:

Zitat von Der schöne Günther (Beitrag 1298976)

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:

Zitat von Der schöne Günther (Beitrag 1298976)

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:

Zitat von Stevie (Beitrag 1298970)

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.

[DualCoreCpu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1298863)

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.

Ich war soeben auf der Webseite, kann dort aber nichts erfahren zu den Lizenzbedingungen. Habe hier einen Altrechner mit Firefox 2.0.0.20. Das sag ich nur, falls die Seite diesen Browser nicht mehr unterstützt.

Wie sind die Konditionen? (Freeware, OpenSource, Shareware, zeitlich begrenzte Testversion, ... )

[ventiseis]

Zitat:

Zitat von quaero (Beitrag 1298924)

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:

Delphi-Quellcode:

TDataCache = TObjectDictionary<string, TList<TData>>