XE3-Compiler-Speicherleck

[Nersgatt]

Zitat:

Zitat von jbg (Beitrag 1188424)

Ich habe mal schnell ein kleines IDE Plugin geschrieben, dass den Speicherverbrauch des Compilers auflistet.

Würden Dir die Ausgaben des Plugins denn bei irgendetwas helfen, dort Besserung zu schaffen? Dann würde Dir das zumailen. Es ist jetzt 7:54, ich arbeite seit 7:30 Uhr. Und genau jetzt werde ich das erste für den heutigen Tag die IDE neu starten, weil sie "Zu wenig Arbeitsspeicher" anmeckert...

[jbg]

Zitat:

Zitat von Nersgatt (Beitrag 1188440)

Würden Dir die Ausgaben des Plugins denn bei irgendetwas helfen

Nicht wirklich. Denn nur wenn die "FreeList" groß wäre, könnte ich was einbauen, das deren Speicher an Windows zurück gibt. Ansonsten kann ich nur die Units entladen (sofern ich dahinter komme wie das geht) aber dann dürfte der Debugger so seine Probleme bekommen. Die Units "sharen" ist nicht wirklich möglich, da dazu der Compiler erheblich verändert werden müsste (Referenzzählung). Das ich das von außen über ein Plugin machen kann ist eher unwahrscheinlich, allein schon daher, dass ich nicht weiß wo überall das eingebaut werden müsste und ich nur noch mit Assembler-Code-Patches hantieren müsste.


UPDATE:
Hab da doch noch eine Idee. Der generierte Code, der in den DCU Dateien liegt sollte sich möglicherweise zusammenfassen lassen. Ich müsste mich also beim Laden der DCU einklinken und die Daten in einen anderen "Unit-Share" Speicherbereich auslagern und beim Freigeben diesen der Unit diesen auch freigeben. Dadurch würden nur noch die Symbole, Typen, Prozedure-Definitionen Platz weg nehmen. Wieviel sich da einsparen lässt muss ich aber vorher noch herausfinden, nicht das ich mir die Arbeit für ein paar Bytes mache.

[Delphi-Laie]

Ist der Fehler (Embarcadero) schon bekannt? Falls nein, könnte das mal bitte jemand dort veröffentlichen? Oder wengistens Herrn Eissing darob informieren?

[Memnarch]

Zitat:

Zitat von jbg (Beitrag 1188463)

da dazu der Compiler erheblich verändert werden müsste (Referenzzählung).

Mh, Wie kommst du den da auf referenzzählung?

[himitsu]

@Delphi-Laie: Jupp, denen isses bekannt.

Zitat:

Zitat von himitsu (Beitrag 1188329)

Krass, es gibt sogar eine eigene Ecke nur für Speicherlecks. :stupid:
http://qc.embarcadero.com/wc/qcmain.aspx?da=5116

http://qc.embarcadero.com/wc/qcmain.aspx?d=81427

@Memnarch: Wenn mehrere Projekte (bzw. deren jeweils eidene Compiler-Instanzen) untereinander die selben Units sharen, dann müßte man wohl irgendwie mitzählen, damit es wieder freigegeben werden kann, wenn es keiner mehr braucht. :wink:

@jbg: Eventuell kannst man auch nur einfach das provuzieren, wie denn man ein Projekt schließt und es wieder öffnet ... also einfach nur den ganzen Cache leeren und auf Anfang zurücksetzen. (falls das einfacher ist)

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1188530)

also einfach nur den ganzen Cache leeren und auf Anfang zurücksetzen. (falls das einfacher ist)

Der Debugger und CodeInsight benötigen ja die Units. Wenn ich es hinbekomme, dass die Units den meisten Speicher teilen, dann dürfte es nicht mehr ganz so extrem Wachsen.

[himitsu]

Wenn Emba den meisten Cachespeicher in MMFs (mit 'ner Tempdatei verknüpft) legen würde, dann könnte selbst die 32 Bit IDE wesentlich mehr Speicher im RAM haben, als nur poplige 32 Bit.
(mit Datei kann man mehr Speicher verschwenden, und müllt die PageFile nicht voll)

Bei Speichermangel (für Windows) wird es in die Datei geschrieben und ansonsten würde die Windows das Wichtigste die meiste Zeit im RAM cachen.

[jbg]

Das ist leider kein Cache im Sinne eines Caches. Die DCU Datei wird eingelesen und dann alle Referenzen, die in der DCU als Index liegen in Pointer umgewandelt. Danach wird während des Kompilierens/Linkes Änderungen an den geladenen Symbolen gemacht (insbesondere Flags). Es fehlt einfach die Trennung zwischen statischen Daten und Arbeitsdaten. Somit kann man nichts zusammen fassen und mit MMFs kann man sich auch nicht behelfen, da schon allein beim Laden der DCUs Änderungen notwendig sind (=> Referenzen auflösen).



Das mit dem generieren Code Zusammenfassen bringt nicht viel. Bei dem Demoprojekt kommen da gesamt gerade einmal 77 MB zusammen. Wenn da doppelte zusammengefasst werden wird es wahrscheinlich auf unter 20 MB fallen, aber das sind Peanuts im Vergleich zu den anderen 600 MB.

[himitsu]

Zitat:

Zitat von jbg (Beitrag 1188556)

Das mit dem generieren Code Zusammenfassen bringt nicht viel.

:cry:

Nja, zumindestens ist mir nun die IDE nicht mehr unter den Fingern wegverreckt. (werde jetzt ja gewarnt :) )

[jbg]

Ich habe jetzt mal deine Idee mit dem "Aufräumen der Units" in den DCC Memory Analyzer eingebaut. Mit der CheckBox kannst du das "Feature" (de)aktivieren um einen Vergleich zu haben.

Wenn die Checkbox gesetzt ist, werden vor dem Kompilieren eines Projekts sämtlichen Units aller anderen Projekte (in allen Platformen) freigegeben.

Ich kann nicht garantieren, dass die IDE bzw. der Compiler sich dabei normal verhalten. Interessant wäre es, wie sich CodeInsight, ErrorInsight, HelpInsight, der Debugger und der Compiler sich verhalten. Funktioniert das Debuggen in ein "anderes (DLL/BPL) Projekt" noch, sieht man die Symbole, ...

Viel Spaß beim Testen.