![]() |
Delphi-Version: XE3
Generics / Speicherprobleme in der IDE
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 ( ![]() 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, ..). |
AW: Generics / Speicherprobleme in der IDE
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
![]() |
AW: Generics / Speicherprobleme in der IDE
Mehrfach vorkommende Typen und Typen, die als Parameter genutzt werden, nur einmal pro Projekt definieren und dann diesen Typ verwenden:
Delphi-Quellcode:
Dann muss dieser Typ nur einmal ins Objektmodell.
TMyIntList = TList<Integer>;
TMeinObject = class FIrgendeineListe: TMyIntList procedure tueWas(const liste: TMyIntList); ... |
AW: Generics / Speicherprobleme in der IDE
Zitat:
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:
|
AW: Generics / Speicherprobleme in der IDE
Das macht den erzeugten Code größer, klar. Aber das soll eine Ursache für das "Out of Memory"-Problem in der IDE sein?
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
Aber genau kann das glaub ich, Andreas beantworten. |
AW: Generics / Speicherprobleme in der IDE
Zitat:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
Wie sind die Konditionen? (Freeware, OpenSource, Shareware, zeitlich begrenzte Testversion, ... ) |
AW: Generics / Speicherprobleme in der IDE
Zitat:
Beispiel:
Delphi-Quellcode:
TDataCache = TObjectDictionary<string, TList<TData>>
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
Zitat:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
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. |
AW: Generics / Speicherprobleme in der IDE
Wahnsinn, das war interessant. :thumb:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
|
AW: Generics / Speicherprobleme in der IDE
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
![]() ![]() |
AW: Generics / Speicherprobleme in der IDE
Liste der Anhänge anzeigen (Anzahl: 1)
Zitat:
Anhang 43041 - trotz deiner URL in der Adresszeile. |
AW: Generics / Speicherprobleme in der IDE
Dann vergleich doch mal die url in deiner Addressleiste mit dem Link den ich im Post zuvor schrieb, ich geb dir nen Tip: RAUTE! :stupid:
|
AW: Generics / Speicherprobleme in der IDE
Zitat:
Liegt vielleicht an dem Uralt-IE in der Arbeit. |
AW: Generics / Speicherprobleme in der IDE
[QUOTE=jbg;1298993][quote]
Zitat:
Code:
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.
Tools > Optionen > Code Insight
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:47 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz