AW: Ide instabil mit hohem Speicherverbrauch
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. |
AW: Ide instabil mit hohem Speicherverbrauch
Zitat:
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) ? |
AW: Ide instabil mit hohem Speicherverbrauch
Vielleicht hilft es ungenutzte Packages abzuwählen?
|
AW: Ide instabil mit hohem Speicherverbrauch
Zitat:
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 :) |
AW: Ide instabil mit hohem Speicherverbrauch
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
|
AW: Ide instabil mit hohem Speicherverbrauch
Zitat:
Siehe: https://quality.embarcadero.com/browse/RSP-18080 Zitat:
|
AW: Ide instabil mit hohem Speicherverbrauch
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:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 18:54 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz