Ide instabil mit hohem Speicherverbrauch

[NicoM]

Hallo,

ich habe eine Frage betreffend der Delphi-Ide. Wir benutzen hier aktuell die Version 10.1 (Berlin) und schon übergangsweise die Version 10.2 (Tokyo). Wir haben mehrere Projekte u.a. mit jeweils bis zu ~4,1 Millionen Codezeilen. Ein Teil der Codezeilen kommt von externen Quellen die direkt als .pas referenziert werden.

Leider wird die Ide sehr schnell instabil. Nachdem ersten Bauen des Projektes was ca. 2 Minuten dauern kann, belegt die Ide 2.5Gb an Speicher, welcher beim nächsten Bauen scheinbar nicht komplett freigegeben wird. So hat man dann bereits 3.2GB belegt und die Bauzeit wird immer langsamer, teils mehr als 6 Minuten. Ein drittes mal Bauen klappt bei den meisten nicht mehr, da die Ide abstürzt oder einfriert.
Ein Projektwechsel innerhalb der Projektgruppe oder ein Clean (meist 2x notwendig, eventuell kommt aber auch eine AccessViolation) kann den Speicher freigeben, so kann man meist weiterarbeiten. Ansonsten bleibt nur der Neustart der Ide. In den letzten Jahren wurde es immer schlimmer, da das Projekt weiter anwächst.

Die externen Quellen als Packages auslagern reduziert den Code auf ~2,7 Millionen Zeilen. Die Bauzeit verringert sich dabei nur um 20 Sekunden, aber der Speicherverbrauch bleibt.

Daher meine Frage, ob jemand hier auch Erfahrungen mit Delphi-Projekten hat, bei dem das Projekt über 2 Millionen Codezeilen hat. Ist das Speicherproblem und die Instabilität ein Fehler der Ide? Hat jemand ähnliche negative Erfahrungen gemacht. Oder gibt es jemand bei dem solche Probleme nicht auftreten?
Wir rätseln hier noch, ob unsere Projekte/Projektestruktur der Grund für die instabile Ide ist oder ob es einfach an den mehreren Millionen Zeilen Code liegt.

mit freundliche Grüßen
Nico M.

[Bernhard Geyer]

Das Problem existiert mindesten schon seit Delphi 6.
Verbesserung ergibt es mit dem bekannten IDEFixPack.
Auch 10.2 hat hier einiges an verbesserung gebraucht.

Für Build-Prozesse solltet ihr einen Buildserver (Jenkins) aufsetzen den ihr mit Batch-Dateien auf Basis von msbuild "füttert".
Diese Batch-Dateien könnte ihr dann auch verwenden wenn ihr auf dem Entwicklungsrechner mal alles neu erstellen wollt.

[NicoM]

Vielen Dank für die Antwort.

Das IDEFixPack sollten alle installiert haben und mit 10.2 ist es schlimmer geworden, daher auch die Frage hier im Forum.

[hoika]

Hallo,
alles was extern ist und sich damit so gut wie nie ändert, würde ich nicht als pas,
sondern nur als dcu reinnehmen.

[DevLinus]

Wie Hoika schon geschrieben hat externe Quellcode als .dcu dateien verwenden. Was bei uns das erzeugen von knapp 7 Minuten auf 2,5 Minute reduziert hat ist, dass wir alle Uses die nicht zum Interface gehören und den Implementation Bereich verschoben haben.

IDE Speicherverbrauch kann man verbessern indem man folgende Sachen macht:

Refactor Funktion entfernen

http://www.delphifeeds.com/go/s/124344

Und das Modern Theme in der Regerstry auschalten.

Kann aber gerne mal eine Delphi Installation zerstören. Angaben ohne Gewähr!

[himitsu]

Man plant für die ferne Zukunft die IDE auf 64 Bit zu heben. (geht nur nicht so leicht, wegen den ganzen Fremdkomponenten und IDE-Plugins, welche dann ebenfalls auf 64 Bit sein müssen)

Einen ersten Bugfix der Symtome gabe es vor 'ner Weile, als in der IDE die 4 GB-Option aktiviert wurde (früher maximal 2 GB und jetzt bis zu 4 GB für die IDE)


Und ja, wenn du Fremdkomponenten und eigene CodeTeile vorkompiliert hast (über eigenständige Projekte/Projektgruppen), dann fallen sie jetzt raus, beschleunigen alles und sparen Speicher.

Oder via Commandline kompilieren.
Die Speicherlecks und ungünstigen Caches fallen dort nicht auf, weil danach immer Compiler/Speicher wieder freigegeben werden.
Unter MainMenu > Tools (Build-Tools...) kannst dir auch einen Aufruf des ComandlineCompilers reinbauen.
Den Aufruf kannst dir in Meldungen > Erzeugen abgucken.

[NicoM]

Vielen Dank.
Wie ich oben schon schrieb haben wir die externen Quellen auf Packates (bpl/dcp) umgestellt. Was den Code auf ~2,7 Millionen Zeilen reduziert. Die Bauzeit verringert sich um 20 Sekunden, aber der Speicherverbrauch bleibt.
Das Problem ist das der Speicher nach einem Build bzw. vor einem neuen Build nicht komplett freigegeben wird und daher sich der Verbrauch mit jedem Build weiter erhöht. Nach dem dritten Build macht die Ide dann nicht mehr mit.

[himitsu]

Zitat:

Zitat von DevLinus (Beitrag 1402429)

dass wir alle Uses die nicht zum Interface gehören und den Implementation Bereich verschoben haben.

Gerade davon würde ich eher abraten.

Besser so viel wie möglich im Interface und nur "absichtliche" Kreuzreferenzen in die Implementation.

Denn in Implementation sind die Unit-Initialisierungen "zufällig", waren im Interface diese Units immer vor deiner Unit initialisiert werden.

[himitsu]

Zitat:

Zitat von NicoM (Beitrag 1402431)

Das Problem ist das der Speicher nach einem Build bzw. vor einem neuen Build nicht komplett freigegeben wird und daher sich der Verbrauch mit jedem Build weiter erhöht. Nach dem dritten Build macht die Ide dann nicht mehr mit.

Darum auch.

Zitat:

Oder via Commandline kompilieren.
Die Speicherlecks und ungünstigen Caches fallen dort nicht auf, weil danach immer Compiler/Speicher wieder freigegeben werden.
Unter MainMenu > Tools (Build-Tools...) kannst dir auch einen Aufruf des ComandlineCompilers reinbauen.
Den Aufruf kannst dir in Meldungen > Erzeugen abgucken.

IDE-FixPack und Co. hacken sich aber in diese Caches ein und verbessern da ein bissl was.

[ventiseis]

Ich glaub nicht, dass man da viel machen kann. Ich vermute (!), die IDE bräuchte mehr Speicher (oder der Speicher wird zu fragmentiert), wie ein 32-bit-Prozess erhalten kann. Abhilfe könnte da nur eine 64-bit IDE schaffen (Wunschdenken!).

Wir haben hier ein ähnliches Problem:

• 1-2 Mio Zeilen code, aber durch den Einsatz von Generics (in vielen typisierten Objektlisten) DCUs, die ca. 17 MB groß sind und nur Code enthalten
• der Speicherverbrauch in Delphi Seattle wächst bis zu 2.5GB an, und die IDE wird extrem träge
• die automatische Vervollständigung im Quelltext lädt zun Kaffeetrinken ein, da es so lange dauert - bei einigen Projekten erhöht sich die benötigte Zeit zum Kompilieren dann mit jedem mal enorm: erst 1, dann 2, dann 8 Minuten
• danach kommt wahlweise eine Fehlermeldung oder die IDE reagiert nicht mehr

IdeFixPack ist installiert, ändert aber an dem Problem nix.