Generics / Speicherprobleme in der IDE

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

[Der schöne Günther]

Wahnsinn, das war interessant.

[ventiseis]

[QUOTE=jbg;1298993][quote]

Zitat von Stevie:

Der ErrorInsight/Refactoring Parser trägt hier die Hauptschuld. Dieser verbraucht nämlich für DCU Dateien den doppelten Speicherplatz.

Kann man das eigentlich irgendwie deaktivieren? Unter

Code:

Tools > Optionen > Code Insight

habe ich alle Checkboxen deaktiviert. Trotzdem bekomme ich über Strg + Leertaste noch eine "Programmierhilfe" und auch mit Strg + Shift + Leertaste werden die Parameterinfos angezeigt. Daher gehe ich davon aus, dass CodeInsight trotzdem läuft.