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.

[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