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.

[NicoM]

Vielen Dank nachmal für die Antworten.

Das mit den Uses im Implementationteil, wie oben erwähnt, ist bei uns auch verboten. Aber es gibt noch alten Code bei dem die Uses im Implementationteil stehen, vor allem scheinbar um zirkulare Referenzen zu ermöglichen. Es gibt die Bestrebung diese Stellen alle umzubauen. Kann es sein, dass solche zirkularen Referenzen dazu beitragen, dass der Speicherverbrauch der Ide beim Build stark ansteigt und nicht wieder freigegeben wird? Hat da jemand fundierte Erfahrung? Das würde uns bei der Priorisierung der Aufgabe zur Beseitigung von zirkularen Referenzen helfen.

[Elrond]

Zitat:

Zitat von himitsu (Beitrag 1402432)

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

Könntest du das genauer erläutern?
Ich verstehe das gerade so das Unit A im initialization Block etwas macht worauf Unit B im ihren initialization Block angewiesen ist.
Wenn Unit B jetzt Unit A im implementation Bereich einbindet, dann kann es sein das Unit B ins leere läuft?


@Topic, reden wir hier gerade übers Compilieren (nie Probleme damit gehabt) oder das Builden (macht der Jenkins) ?

[KodeZwerg]

Vielleicht hilft es ungenutzte Packages abzuwählen?

[Uwe Raabe]

Zitat:

Zitat von NicoM (Beitrag 1402723)

Kann es sein, dass solche zirkularen Referenzen dazu beitragen, dass der Speicherverbrauch der Ide beim Build stark ansteigt und nicht wieder freigegeben wird? Hat da jemand fundierte Erfahrung?

Nach meiner (fundierten?) Erfahrung machen zirkuläre Unit-Referenzen sehr wohl Probleme und sind eine der Ursachen für z.B. IDE-Instabilitäten und den Ausfall von Code Insight. Es kommt auch vor, daß man zwingend ein Build machen muss, weil ein simples Compile entweder fehlschlägt oder zu merkwürdigem Programmverhalten führt (häufig beim Debuggen).

Zirkuläre Referenzen sind mittlerweile das Erste, was ich bei einem bestehendem Projekt eliminiere, wenn ich es übernehme. Im Ergebnis hat man dann eine stabile und funktionsfähige IDE (OK, Bugs gibt's immer). Compilieren geht zumindest gefühlt auch schneller.

Ach ja, ich kenne da ein hilfreiches Tool: Unit Dependency Analyzer :)

[KodeZwerg]

Wenn es nicht unbedingt die IDE sein muss kann ich auch das hier empfehlen, sehr cooler IDE Ersatz um schnell mal Dinge zu erledigen, auch Compilieren etc. Pascal Project Manager & Editor 2.03

[Stevie]

Zitat:

Zitat von ventiseis (Beitrag 1402439)

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

Ich habe ja seit langem schon in Verdacht, dass Generics (genauer einige Defekte in Implementierung/Design im Compiler) zu diesem Problem beitragen.
Siehe: https://quality.embarcadero.com/browse/RSP-18080

Zitat:

Zitat von Uwe Raabe (Beitrag 1402743)

Zitat:

Zitat von NicoM (Beitrag 1402723)

Kann es sein, dass solche zirkularen Referenzen dazu beitragen, dass der Speicherverbrauch der Ide beim Build stark ansteigt und nicht wieder freigegeben wird? Hat da jemand fundierte Erfahrung?

Nach meiner (fundierten?) Erfahrung machen zirkuläre Unit-Referenzen sehr wohl Probleme und sind eine der Ursachen für z.B. IDE-Instabilitäten und den Ausfall von Code Insight. Es kommt auch vor, daß man zwingend ein Build machen muss, weil ein simples Compile entweder fehlschlägt oder zu merkwürdigem Programmverhalten führt (häufig beim Debuggen).

Zirkuläre Referenzen sind mittlerweile das Erste, was ich bei einem bestehendem Projekt eliminiere, wenn ich es übernehme. Im Ergebnis hat man dann eine stabile und funktionsfähige IDE (OK, Bugs gibt's immer). Compilieren geht zumindest gefühlt auch schneller.

Ach ja, ich kenne da ein hilfreiches Tool: Unit Dependency Analyzer :)

Das ist aber auch nur Symptombekämpfung und aufgrund von fehlenden Sprachfeatures (z.B. partial Classes, Sichtbarkeit "internal", Extension Methods) oft leider die einzige Möglichkeit, bestimmte Architekturen zu realisieren. Wenn man nicht in der Lage ist, syntaktisch korrekten Code zu schreiben, weil die IDE es nicht gerafft bekommt, ist das für mich Kategorie unterirdisch und disqualifiziert diese Sprache/IDE, rosarote Brille oder Delphi Fan der ersten Stunde hin oder her.

[MichaelT]

Nimm VMMAP (von Sysinternals) selektiere die BDS und mache Tools Empty Working Set.

Ich könnte mir vorstellen dass Filesystem Puffer das Problem verursachen.

Gehe nicht in RamMAP und mache schon gar nicht Empty Modified Page List. Dann ist zwar zusammengeräumt aber viel geht nicht mehr. Dort hat Empty StandBy List zumindest mal kurzfristig geholfen. Dann waren alle Einträge ins Project Directory weg und nach dem nächsten Build wieder da.

Ich weiß nicht ob das hilft. Aber bei mir stellt es die BDS zumindest wieder zurück auf den Speicherverbrauch nach Start zumindest lt. Anzeige im Taskmanager.

Lt. VMMAP verbraucht Delphi 880MB nach Start bei mir und hat aber bis 4GB frei.

Ob das viel bringt ist ein anderes Thema. Aber möglw. hilft es vorübergehend.

Am Ende wird vermutlich die Verlagerung auf einen Build Server mehr bringen.

--- Zum Code ---
Ich habe keine großen Programme. Ich bin besser damit gefahren, wohl zyklische Abhängigkeiten vermeidend, units dann einzubinden wenn ich sie brauche auch in der Implementation und diese habe keine Initialization und Finalization Section.

--- 10.2 Tokyo --
Obwohl ich keine Delphi Speedup habe und selbst wenn ich alles aufdrehe läuft das durchwegs stabil.

Allein habe ich allein die beiden Punkte bezüglich Tooltips bei den Code Insight Einstellungen aktiv und sonst nichts. Für den Rest verwende ich eine Mini Version von CnPack.

Zitat:

Zitat von NicoM (Beitrag 1402415)

mit freundliche Grüßen
Nico M.