Ide instabil mit hohem Speicherverbrauch

[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 von himitsu:

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 von NicoM:

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 von ventiseis:

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 von Uwe Raabe:

Zitat von NicoM:

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 von NicoM:

mit freundliche Grüßen
Nico M.