Generics / Speicherprobleme in der IDE

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