XE3-Compiler-Speicherleck

[jbg]

Zitat von himitsu:

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

Das mit dem generieren Code Zusammenfassen bringt nicht viel.

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.

[Kidi]

Hallo alle zusammen,
ich habe die Dll ins Delphi Bin Verzeichnis kopiert.
Nun startet Delphi nimmer, sondern verweist auf eine Interneseite von Embarcadero mit der Fehlermeldung "Product or License Validation Error".
Liegt der Fehler an der Dll oder muß diese in ein anderes Verzeichnis?

Grüße
Dietmar

[USchuster]

Zitat von Kidi:

Hallo alle zusammen,
ich habe die Dll ins Delphi Bin Verzeichnis kopiert.
Nun startet Delphi nimmer, sondern verweist auf eine Interneseite von Embarcadero mit der Fehlermeldung "Product or License Validation Error".
Liegt der Fehler an der Dll oder muß diese in ein anderes Verzeichnis?

Das ist ganz normal - also die DLL muss in ein anderes Verzeichnis. Das ist XE3 wo jede DLL in $(BDSBIN) signiert sein muss. Das man Dateien neu signieren kann hat EMBT wohl niemand gesagt.

[sh17]

Gibts da was neues oder ist das im aktuellen Update von XE3 behoben? Ich bekomm nicht mal meine Projektgruppe mit schon ein paar Projekten durchkompiliert ohne die 1.x GB zu durchbrechen.