XE3-Compiler-Speicherleck

[himitsu]

Im Prinzip ist das doch noch ein recht kleines Projektchen und ich komm jetzt schon an die Grenzen der IDE ... was soll denn passieren, wenn man da mal richtig an die Arbeit geht?

Zitat von Memnarch:

Mh habe ich das richtig gelsen, dass du mehrere megabyte kompiliert hast? Bin bei der aufzählung etwas verwirrt.

Kommt drauf an, von welcher Seite man das betrachtet.
Auf Seite der Quellcodes sind's nur ein paar Kilobyte

178 Quelldateien (PAS/DFM/DPR/DPK) = 2,2 MB
=
70 DCUs = 1,99 MB (inkl. Debuginfos)
47 EXE/DLL/BPLs = 84,6 MB (als Debug-Build)
1,2 GB welche in der IDE beim Kompilieren entstehen

340.000 Zeilen als Build All = 1,3 GB RAM
36.700 Zeilen als Compile All = 1,3 GB RAM (konnte ich bis vor wenige Minuten nicht machen, da es mehrere gleichnamige Units gab)
Mehrfaches Kompilieren einer Unit macht verursacht wenigstens nicht gleich mehr Speicher.


@jbg:
Jupp.
http://FNSE.de/DL/PHP4Delphi%208.0%202012-10-21%20[himitsu].7z (noch nicht fertig)
Versuche ein paar Fehler rauszumachen, welche bei der Umstellung auf Unicode eingebaut wurden und nebenbei alle APIs überarbeiten/prüfen, damit es auch mal mit 64 Bit zurechtkommt.

[himitsu]

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

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

[jbg]

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

Installation:
Unter
[HKCU\Software\Embarcadero\BDS\10.0\Experts]
den Eintrag
"DccMemAnalyzer_Debug"="C:\Somewhere\On\My\Disk\Dc cMemAnalyzer.dll"
eintragen und die IDE starten.
Danach sollte schon während des Splashscreens ein Fenster mit einem Memo aufgehen. Der Button "Refresh" füllt das Memo mit den aktuellen Speichermanager Daten des Compilers.

Nach dem Kompilieren sieht man, dass über 700 MB an Units geladen sind. Für jedes kompiliertes Projekt wird der gesamte Unit-Betand (System.dcu, SysUtils, Classes.dcu, ...) gehalten, was das ganze so dermaßen aufbläst.

[himitsu]

Zitat:

Für jedes kompiliertes Projekt wird der gesamte Unit-Betand

Toll, grade die Units, welche den größten Teil an den meinen/diesen Projekten ausmachen.
Das heißt also, wenn die es irgendwann mal lernen Resourcen mehrfach zu nutzen, daß ich doch keine 64-Bit-IDE benötige.




Ich hatte es vorhin, alleine mit dem Bearbeiten vieler Units, geschafft, die IDE abstürzen zu lassen.

War auch noch so im Tippen vertieft, daß ich nicht alle 2 Sekunden gespeichert hatte.
Fazit: Ausreichend Arbeit war umsonst. Danke Emba.

Ich vermute mal, daß hier das Code Insight dran Schuld war, welches ständig im Hintergrund rumkompiliert.


Hab mir jetzt erstmal 'nen billigen Wächter erstellt, der mich jetzt wenigstens etwas vorwarnt.

Du sagtest doch vorhin was davon, daß der Speichermanager des Compileres eine Aufräumfunktion hat.
Könnte man diese irgendwie aufrufen? (ohne daß es danach knallt)


Bezüglich dem "seit XE ist der Compiler/Compilierspeicher an Projekte gebunden", das erklärt auch noch ein anderes Phänomen, welches mich schon etwas genervt hat.

Früher konnte man schnell mal eine billige Unit erstellen oder öffnen, ohne daß sie zu einem geladenem Projekt gehört und hatte darin dennoch Funktionen, wie Code Insight und Dergleichen, zur Verfügung.
Das funktioniert jetzt leider auch nicht mehr.

[himitsu]

Der RAM läuft nimmer über und das Code-Insight scheint bisher problemlos zu funktionieren.

Einmal (von 3-4 Durchgängen), ist der Compilier mittendrin abgebrochen "Es ist ein Fehler aufgetreten" und sonst wurde nichts gesagt, aber IDE und Compiler lief danach ohne Probleme weiter.

Im Prinzip könntest du ja vorher den Speicher prüfen und nur alles freigeben, wenn z.B. keine 500 MB mehr frei sind, damit würdest du nicht so häufig eingreifen.

[Nersgatt]

Zitat von jbg:

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

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

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

Krass, es gibt sogar eine eigene Ecke nur für Speicherlecks.
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.

@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)