XE7 Memory verbrauch untragbar.

[ventiseis]

Gibt es eigentlich für diese ständigen Speicherprobleme irgendeinen Workaround? Es gibt einige offene Einträge dazu in der QC für verschiedene Delphi-Versionen - aber einen Workaround habe ich bisher nicht ausmachen können.

Meist verabschiedet sich die IDE bei so ca. 1GB verbrauchten Arbeitsspeicher - warum kann Delphi eigentlich die 2GB nicht ausnutzen?

Kann man (irgendwas) innerhalb der IDE ausschalten, damit das Problem wenigstens nicht so häufig auftritt? Wie haben hier ein Delphi-Projekt (XE3) mit vielen Generics, da muss nach dreimal kompilieren die IDE neu gestartet werden. IdeFixPack / ddev-Extensions bringen leider auch keine Abhilfe. Und nach den beschriebenen Problemen in späteren Delphi-Version scheint ein Update auch keine Lösung zu sein.

[Insider2004]

Der QC wird nicht so schnell gelöst werden. Die XE+ IDEs sind ein Sammelsurium aus Delphi, C++, Java, J#, C# und was weiss ich noch alles. Irgendwas verhindert immer wieder, das man das als 64 bit app kompiliert. Wie ich EMBA kenne, dauert das noch mal 5 Jahre. So 2020 werden wir frühestens eine 64 bit IDE sehen. Vielleicht auch gar nicht.

[bepe]

Habe mit Mobile nichts am Hut aber klassische VCL Projekte mit mehreren Millionen Zeilen Quelltext auf ein dutzend Projekte verteilt und per Gruppe erzeugt, wird von meinem XE7 tadellos verarbeitet. Speicherverbrauch unter 500 MB...

Aber wenn ich die kostenlose Castalia Version installiere steigt der Verbrauch um 1gb und Arbeiten wird unmöglich. Vielleicht ist Delphi diesmal unschuldig?

[jaenicke]

Zitat von ventiseis:

Und nach den beschriebenen Problemen in späteren Delphi-Version scheint ein Update auch keine Lösung zu sein.

Das ist mit XE6 bei uns deutlich besser geworden. So heftig war das Problem bei uns aber auch nie.
Du kannst zumindest in den aktuellen Versionen aber den externen Compiler einstellen, damit der statt des internen benutzt wird. Das löst das Problem bei uns absolut.

Einziges Problem, das wir in XE6 hatten (bei XE7 hatte ich das bisher nicht, habe es aber auch nicht intensiv getestet):
Beim Debuggen von DLLs steigt die IDE immer wieder mal aus. Leider nicht reproduzierbar, am vollen Speicher scheint es aber nicht zu liegen, der Verbrauch ist moderat.

[ventiseis]

Zitat von jaenicke:

Du kannst zumindest in den aktuellen Versionen aber den externen Compiler einstellen, damit der statt des internen benutzt wird. Das löst das Problem bei uns absolut.

Kann man dann trotzdem Debuggen? Wir kompilieren zum Teil auch jetzt schon mit MSBUILD, klickt man danach in der IDE auf Debugging, wird natürlich erneut kompiliert, obwohl die fertige Exe im Ausgabeverzeichnis liegt...

[himitsu]

Kompiliert ihr beim debuggen über den erwähnten "externen Compiler", oder mit dem Delphi-Compiler?

Wenn man den CommandLineCompiler vom Delphi dafür verwendet (externen Compiler), dann müssten die selben Compilate bei rauskommen, wie beim InlineCompiler.
Ob der Debugger mit den Compilaten des externen MSBUILD klar kommt ... k.A., aber wenn, dann natürlich nur, wenn mit den nötigen Debuginfos kompiliert wurde.

Solange man alle Parameter richtig übergibt.
Aber der Aufruf wird ja praktischer Weise im Compiler-Log angezeigt, welchen man verwenden könnte.

[ventiseis]

Zitat von himitsu:

Kompiliert ihr beim debuggen über den erwähnten "externen Compiler", oder mit dem Delphi-Compiler?

In XE3 gibts es die Checkbox für den "externen Compiler" noch nicht.

Soweit ich das verstanden habe, ruft

Code:

msbuild Demo.dproj /t:Build

dann wieder z.B. dcc32.exe mit allen notwendigen "Compilerschalten" auf.

[jaenicke]

Zitat von ventiseis:

Kann man dann trotzdem Debuggen? Wir kompilieren zum Teil auch jetzt schon mit MSBUILD, klickt man danach in der IDE auf Debugging, wird natürlich erneut kompiliert, obwohl die fertige Exe im Ausgabeverzeichnis liegt...

In so einem Fall würde ich nicht F9 drücken, sondern mit der laufenden Exe verbinden (Start --> Mit Prozess verbinden...) oder die Exe durch den Debugger starten lassen (Start --> Prozess laden...).
Die Debuginfos müssen natürlich vorhanden sein (dafür müssen es wohl externe Debuginfos sein, sprich die .rsm Datei).

Wenn du in den Projektoptionen "MSBuild extern für die Compilierung verwenden" aktivierst, kannst du auch ohne externe Debuginfos normal mit F9 debuggen, ja. Mankos sind:
Fehler werden beim Kompilieren nur noch zeilenweise angezeigt statt die direkte Fehlerstelle zu markieren.
Die Projektdateien müssen gespeichert sein, sprich wenn man das automatische Speichern nicht aktiviert hat, gibt es "lustige" Effekte...

[ventiseis]

Zitat von jaenicke:

In so einem Fall würde ich nicht F9 drücken, sondern mit der laufenden Exe verbinden (Start --> Mit Prozess verbinden...) oder die Exe durch den Debugger starten lassen (Start --> Prozess laden...).
Die Debuginfos müssen natürlich vorhanden sein (dafür müssen es wohl externe Debuginfos sein, sprich die .rsm Datei).

Danke für den Tipp Werde ich demnächst probieren!

[Ursa]

Kann man innerhalb der IDE ausschalten, damit das Problem wenigstens nicht so häufig auftritt.





samsung galaxy trend lite schutzhülle