Entwickler-Ecke

Programmierwerkzeuge - Ide instabil mit hohem Speicherverbrauch


NicoM - Do 17.05.18 15:55
Titel: Ide instabil mit hohem Speicherverbrauch
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.


Moderiert von user profile iconNarses: Topic aus Sonstiges (Delphi) verschoben am Do 17.05.2018 um 23:07


mael - Fr 18.05.18 17:57

Ohne konkret was zu diesem Problem sagen zu können (habe diese Versionen nicht), könnte es sich lohnen Pakete/Packages zu erzeugen, so dass nicht immer der ganze Quelltext kompiliert werden muss.
Die DCUs sollten auch für x64/x86 in verschiedene Verzeichnisse, und dann nochmals jeweils für Release/Debug (Siehe Projekt/Packageoptionen).

Es wäre möglich dass DCUs die nicht zusammenpassen die IDE durcheinander bringen. Vielleicht gibt es auch Pfadprobleme.

Allgemein sollte man nur PAS-Dateien direkt einbinden die auch wirklich zum Projekt gehören, und keine die zwischen mehreren Projekten geteilt werden. Dort besser vorkompilierte DCUs einbinden (durch passend gesetzte Pfade) und diese PAS-Dateien nur einmal kompilieren (durch ein Package).

Vielleicht ist es auch ein Problem mit CodeInsight oder Codevervollständigung (kann man in den Optionen ausschalten).


jaenicke - So 20.05.18 06:31

Wir benutzen auch 10.2. Das läuft bei uns sehr viel stabiler als ältere Versionen wie XE oder XE6. Bei XE gab es regelmäßig interne Fehler und Abstürze, bei XE6 stürzte die IDE auch immer wieder mal ab, insbesondere bei größeren Projekten, in Projektgruppen und beim Debuggen. Sehr schön, wenn man im Debugger gerade den Fehler gefunden hatte und dann der Debugger fest hing und es nicht mehr weiterging...

Bei 10.2 hatte ich zwar auch schon Abstürze, aber nicht mehr so oft und nicht mehr an so kritischen (weil zeitaufwendigen) Stellen wie beim Debuggen. Der Speicherbedarf ist zwar niedriger als bei XE6 und ist insbesondere in Projektgruppen und bei deren Erstellung nicht mehr ein Problem wie bei XE6, aber bei vielen Dateien im Projekt kann es dennoch Probleme geben.

Deshalb ist der von user profile iconmael gegebene (und für externe Units ja auch schon von euch benutzte) Tipp schon richtig. Normalerweise kompiliert man ein oder mehrere Packages um im Projekt nicht so viele Units direkt einbinden zu müssen und stattdessen die dcu Dateien nutzen zu können. Der Ausgabepfad kommt in den Bibliothekspfad, die Quelltextverzeichnisse in den Suchpfad. (Wobei der Bibliothekspfad projektbezogen in den Projektoptionen leider Suchpfad heißt, das kann etwas verwirren.)
Der Suchpfad sorgt dafür, dass die Quelltexte zum Debuggen gefunden werden.
Ihr habt das Auslagern ja auch schon gemacht, aber habt ihr die Pfade auch so gesetzt?

Ihr könnt auch mal in den Projektoptionen das Kompilieren mit msbuild aktivieren. Das bringt normalerweise sehr viel.

Leider wird die Umstellung der IDE auf 64-Bit noch etwas brauchen... erst dann wird das Speicherproblem wirklich erledigt sein.


Sinspin - Mo 21.05.18 09:26

Ich nutze auch 10.2. Abgesehen von der kaotischen Komponenten installation dank Win10 bin ich bisher recht zufrieden, eines der Projekte hat fast 2Mio LOC. Ich kann wiederholt übersetzen ohne die IDE in Stücke zu reißen. Geschwindigkeit kann ich schwer beurteilen, ich arbeite in einer VM, Festplatte ist SSD.
Der Speicherverbrauch ist eindeutig höher als bei XE2.
Bei XE2 ging nichts mehr ohne das IDE-Fixpack, aktuell komme ich ohne aus.


NicoM - Di 22.05.18 07:58

Vielen Dank für die Antworten.

Das mit den Packages haben wir schon gemacht. Dadurch hat sich, wie bereits oben erwähnt, die Anzahl Zeilen auf 2,7 reduziert. Leider ändert das nicht viel am Speicherverbrauch, so dass die Ide dennoch instabil wird nach dem Bauen, da der Speicher nicht freigegeben wird.

mit freundlichen Grüßen
NicoM


Sinspin - Di 22.05.18 08:23

Richtig, Speicherverbrauch! Das war für mich der Nummer 1 Grund das IDE-FixPack [http://andy.jgknet.de/blog/ide-tools/ide-fix-pack/] zu installieren.
Zumindest bei XE2 war das die einzige Möglichkeit mehr als zweimal übersetzen zu können ohne die IDE neu zustarten.


NicoM - Mi 23.05.18 08:05

Vielen Dank für die Antworten.

Kann es sein das zirkulare Referenzen im Code dazu beitragen, dass der Speicherverbrauch der Ide beim Build ansteigt und nicht mehr freigegeben wird?
Kann da jemand eine fundierte Aussage zu treffen?