XE7 Memory verbrauch untragbar.

[ventiseis]

Zitat:

Zitat von jaenicke (Beitrag 1275243)

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. :angel:

[jaenicke]

Zitat:

Zitat von ventiseis (Beitrag 1275246)

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:

Zitat von himitsu (Beitrag 1275248)

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.

[ventiseis]

Zitat:

Zitat von jaenicke (Beitrag 1275255)

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!

[Bambini]

Zitat:

Zitat von Mavarik (Beitrag 1273139)

Ein Build (Android App mit 31xxx Lines) und schon verbraucht die IDE 1GB Speicher!

Arbeitet sonst noch jemand mit XE7?

Mavarik

Das ist vermutlich ein BUG im Quelltext Parser für Code- und Error-Inside.
Der kommt mit dem Quelltext von einigen Units nicht zurecht.
https://quality.embarcadero.com/browse/RSP-9568

[Alex_ITA01]

Hallo zusammen,
ich wollte mich zu dem Thema auch mal äußern.

Wir haben bei uns im Betrieb eine ProjektGruppe mit 17 Projekten (Win32).
Jedes hat so im Durchschnitt 500.000 Zeilen Quelltext.
Die meisten Quelltextzeilen von den 500.000 sind immer die gleichen, also in extra Units, die dann eben von dem ausgewählten Projekt genutzt wird. Also es sind nicht immer 500.000 unterschiedliche von Projekt zu Projekt.

Früher (in XE4/D2009), war Alt+P+K ("Alle Projekte erzeugen") gar kein Problem.
Mit XE7 braucht man es gar nicht zu versuchen!

Man kann ca. 5 Projekte machen, dann ist zwingend ein Neustart der IDE erforderlich.
Der Speicher steht bei 1,2 GB und damit ist Schluss.

Warum hört die IDE bei 1,2GB auf obwohl eine 32bit Anwendung bis zu 2GB kann?

Außerdem ist eine Betrachtung der Speicherauslastung der IDE im Taskmanager schlimmer als eine Achterbahnfahrt. So wie der Speicher da hoch und mal runter geht, fragt man sich, was passiert da überhaupt?

Auch sehr toll ist das Refactoring innerhalb eines Projektes dieser Projektgruppe.
Wenn man da eine Variable innerhalb EINER Unit umbenennen will (und diese kommt in dieser EINEN Unit nur 3x! vor), dann ist der Speicher auch wieder an die 1,2GB Grenze gestoßen nach dem Refactoring.

Fazit: "Nutzbar" ist die IDE bei großen Projekten (innerhalb einer Projektgruppe) leider fast gar nicht.
Also man muss sich dran gewöhnen, regelmäßig einen Neustart der IDE durchzuführen weil sonst Delphi irgendwann mal meldet: Nicht genügend Speicher

OS: Win8.1, 64bit, 16GB RAM

Ich hoffe da wird etwas dran gemacht aber wahrscheinlich liegt da kein Schwerpunkt bei Embarcadero drauf, lieber immer neue Sachen nachbauen, anstatt mal vorhandene Sachen zu optimieren.

Viele Grüße

[Der schöne Günther]

Ich kann überhaupt keine nackten Zahlen beitragen, aber subjektiv kommt mir die IDE nach dem Sprung von XE5.1 auf XE7 auch deutlich langsamer vor. Die IDE braucht schrecklich lange, um ein Projekt zu öffnen. Sekundenlang tut sich nichts.

Mit Speicherverbrauch hatte bislang noch keine Probleme, wahrscheinlich sind unsere Projekte alle zu popelig :oops:

[Insider2004]

Emba kann die XE7-IDE nicht für 64 bit (=unendlich viel freier Speicher) nicht übersetzen, weil da alle möglichen Technologien verwendet werden. Jetzt rächt sich das schlechte Frickel-Design, das über Jahre, trotz Kritik, gepflegt wurde. Ausserdem wurden die Experten alle gefeuert und die Leute im Osten haben auch nicht gerade die Motivation, das zu verbessern (Gehaltsfrage).

[Alex_ITA01]

Moin zusammen,
mich würde trotzdem mal interessieren, warum hört die IDE bei 1,2GB auf obwohl eine 32bit Anwendung bis zu 2GB kann?

Viele Grüße