XE7 Memory verbrauch untragbar.

[Mavarik]

Hallo Zusammen!

Es war ja schon ätzend genug, dass man XE6 nach 3-4 Build (Android) oder 8-10 Build (Win32) neu starten musste, weil kein Speicher mehr da war, aber jetzt mit XE7 ist es echt ne Katastrophe.

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

Arbeitet sonst noch jemand mit XE7?

Mavarik

[Der schöne Günther]

Ich bin hauptsächlich noch auf XE5.1, aber bislang ist mir bei XE7 (für Win32) nichts aufgefallen, trotz zahlreichen Add-Ons (cnPack, gexperts, IDE Fix Pack, ...)

[Mavarik]

Hast Du ein Projekt von einer mobilen App mal reingeladen?

Plötzlich werden alle Dateien die im Projektordner lagen mit auf das Device deployed...

Beispiel:

- Bilder.RC
- Build.Bat
- todo.txt

[Der schöne Günther]

Hast du "What's new in XE7: Project Files Are Automatically Added to the Deployment Manager" gesehen? Vielleicht ist es das...

[Uwe Raabe]

Das kann ich so nicht direkt nachvollziehen. Ich habe zwar jetzt kein Android-Projekt ähnlicher Größe, aber auch ein mehrmaliges Build einer Win32-App mit > 800.000 Zeilen bringt den verwendeten Speicher hier nicht dauerhaft über 450 MB. Das meiste davon wird auch nach dem Schließen des Projekts wieder freigegeben.

[himitsu]

Und ich dachte das Speicherleck (und der geile Cache) im Inline-Compiler wurde langsam mal behoben?

Beim CommandLine-Compiler fällt es ja nicht auf, da der ständig neu gestartet wird. :roll:


PS: Selbst in XE kann man keine "größere" Projektgruppe auf einmal durchkompilieren.

Habt ihr das coole Tool vom Andy eingebunden?
Der räumt den Cache ein bissl auf (wenn ich mich nicht irre).



In meinem XE3 ist auch lange nichts mehr aufgefallen, aber bei einer Hardcoresession anfang des Jahres ist mein Warncode plötzlich angesprungen, welchen ich fast schon vergessen hatte. :lol:
Hier gibt es irgendwo einen Thread, wo ich auch mal solche Speicherprobleme hatte und dabei hatte ich mir eine BPL mit einem Thread oder Timer in die IDE eingebunden, wo dann bei vollem RAM kurz vorher eine Warnung kommt, so ala "He, der RAM ist gleich voll ... Willst du nicht lieber noch schnell speichern, bevor alles abraucht?".
Und Andy hatte da auch noch ein paar interne Dinge verraten, bzw. es gab ein Tool von ihm, welches da versucht bissl aufzuräumen.

[Bernhard Geyer]

Hier meine Daten bezüglich Speicherverbrauch (Arbeitssats aus Taskmanager)

Nach Start (ohne Projekt)
D6: 87 MB
XE6: 33 MB
XE7: 31 MB

Mit Projekt (Projekt.dpr-Datei geöffnet, 32 Bit-Anwendung, ca. 2 Mio. Quellcodezeilen)
D6: 89 MB
XE6: 350 MB
XE7: 323 MB

Nochmaliger kompletter Rebuild:
D6: 225 MB
XE6: 545 MB
XE7: 524 MB

Und nochmal kompletter Rebuild:
D6: 229 MB / 234 / 235
XE6: 548 MB / 547 / 549
XE7: 544 MB / 546 / 547

Übrigens. Für Projektgruppen compilieren ist es doch viel schöner Batch-Dateien mittels MSBUILD zu erstellen.
Oder am besten gleich einen Buildserver :-)

[cookie22]

Zitat:

Zitat von Mavarik (Beitrag 1273139)

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

Wieviel GB hat dein Arbeitsrechner? 2GB? Meiner hat 16GB da würde mich 1GB nicht kratzen.

[Mavarik]

Zitat:

Zitat von cookie22 (Beitrag 1273165)

Zitat:

Zitat von Mavarik (Beitrag 1273139)

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

Wieviel GB hat dein Arbeitsrechner? 2GB? Meiner hat 16GB da würde mich 1GB nicht kratzen.

Habe der VM auch mal 16GB von den 32GB Arbeitsspeicher zugewiesen... Das 1GB stört mich nur deswegen, weil die IDE meldet - nicht genug Arbeitsspeicher!

[Uwe Raabe]

Zitat:

Zitat von cookie22 (Beitrag 1273165)

Wieviel GB hat dein Arbeitsrechner? 2GB? Meiner hat 16GB da würde mich 1GB nicht kratzen.

Die IDE ist aber ein 32-Bit Prozess und hat somit faktisch eine architekturbedingte Grenze von 2GB. Meistens bekommt man bei etwas über 1 GB Speicherverbrauch auch schon die von Mavarik erwähnte Meldung. Insofern sind seine Bedenken sicher gerechtfertigt. Es wäre nur schön die genauen Kriterien dafür zu ermitteln, damit man auch einen reproduzierbaren Testfall auf den Tisch legen kann.

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1273171)

Die IDE ist aber ein 32-Bit Prozess und hat somit faktisch eine architekturbedingte Grenze von 2GB. Meistens bekommt man bei etwas über 1 GB Speicherverbrauch auch schon die von Mavarik erwähnte Meldung. Insofern sind seine Bedenken sicher gerechtfertigt. Es wäre nur schön die genauen Kriterien dafür zu ermitteln, damit man auch einen reproduzierbaren Testfall auf den Tisch legen kann.

Hab da mal ein Video von gemacht...

IDE neu gestartet... Projekt geladen... ein Build...(Beim 2. Mal wird's mehr)

Abgesehen vom Linux-Linker - oder was auch immer das ist - der mal eben auch 1GB braucht.

Mavarik

[Bernhard Geyer]

Hast du auch Virenscanner und Co. so konfiguriert das sie nich in jedes pas/dcu/...-Datei schauen?

[Mavarik]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1273176)

Hast du auch Virenscanner und Co. so konfiguriert das sie nich in jedes pas/dcu/...-Datei schauen?

Nein - und die Verzeichnisse sind sowieso ausgeschlossen!

[newbe]

@der schöne Günter

.. mal OT jetz. Wo hast du den CnPack für XE7 her? Habe im Inet noch kein Build mit offizieller Unterstützung gefunden.

mfg newbe

[himitsu]

Ich les da überall was von XE7. :angel:

http://www.cnpack.org/downbuilds.php?lang=en
https://github.com/cnpack/cnvcl
https://github.com/cnpack/cnwizards
...

[Der schöne Günther]

Wenn man direkt auf cnPack.org geht, sieht man es zugegebenermaßen auch nicht. Man muss oben auf "Nightly Build" gehen. Da muss man auch erst mal drauf kommen 8-)

[jensw_2000]

Der ganze Ärger ändert aber nichts an der Tatsache, dass Windows einem 32bit Prozess einen Adressraum von 2GB gewährt.
1GB Speicherverbrauch ist zwar nicht ganz so wenig, aber wenn man das mal genau durchrechnet ... :gruebel: ... ist es immerhin nur die Hälfte des Möglichen. Da müssten sich also noch echte Bugs im Build Prozess befinden.

Mal so nebenbei, rein interessehalber, nicht böse gemeint und kein Flamen ...
31000+ Zeilen Code? Für eine mobile Anwendung? Heftig!
Kannst Du einschätzen wie viele Zeilen Du geschrieben hast und wie viele Zeilen aus der RTL hinzukommen?
Meine letzte iOS App hatte im Vergleich dazu 800 Zeilen Code verteilt auf 14 TableViewController und 10 Model Klassen. Ein paar UI Spielereien waren auch drin. Für eine kleine iOS App also nicht ganz so klein. Das war so eine Art Tutorial App. Daher habe ich Models und Controller Logik teilweise mehrfach geschrieben, damit ich den Quellcode für die "Leser" schön in separate Unterordner legen konnte. Das Kürzen auf 600 Zeilen wären also keine Hürde gewesen.
Was schreibt man im Mobile Bereich in 31000 Zeilen? :gruebel:

[Mavarik]

Zitat:

Zitat von jensw_2000 (Beitrag 1273250)

Mal so nebenbei, rein interessehalber, nicht böse gemeint und kein Flamen ...
31000+ Zeilen Code? Für eine mobile Anwendung? Heftig!
Kannst Du einschätzen wie viele Zeilen Du geschrieben hast und wie viele Zeilen aus der RTL hinzukommen?

Aus der RTL? Die wird nicht mit compiliert.

Zugegeben 11000 Zeilen davon sind von TMS...
Die Restlichen bilden jedoch die App und das ist leider erst der Rumpf mit minimal Funktionalität.

Mavarik

[jensw_2000]

[QUOTE=Mavarik;1273276]

Zitat:

Zitat von jensw_2000 (Beitrag 1273250)

Die Restlichen bilden jedoch die App und das ist leider erst der Rumpf mit minimal Funktionalität.
Mavarik

Na dann gutes Gelingen! Gib's rüber und lass EMBT suchen.

[Mavarik]

Zitat:

Zitat von jensw_2000 (Beitrag 1273279)

Na dann gutes Gelingen! Gib's rüber und lass EMBT suchen.

QC ist raus..

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1273276)

Zugegeben 11000 Zeilen davon sind von TMS...
Die Restlichen bilden jedoch die App und das ist leider erst der Rumpf mit minimal Funktionalität.

Und genau deshalb kompiliert man 3rd Party Zeugs nich selbst jedesmal, sondern legt seinen Library Path auf das Verzeichnis wo einzig die dcus liegen. :wall:

[Mavarik]

Zitat:

Zitat von Stevie (Beitrag 1273440)

Und genau deshalb kompiliert man 3rd Party Zeugs nicht selbst jedesmal, sondern legt seinen Library Path auf das Verzeichnis wo einzig die dcus liegen. :wall:

Da gebe ich Dir natürlich recht, für den Fall das die 3rd Party Librarys fehlerfrei sind. Leider ist das nicht so - sorry Bruno - und daher möchte ich schon mit dem Debugger im Source an die richtige Stelle kommen, bei einer Exception oder beim debuggen.

Oder habe ich da etwas falsch verstanden, gibt es eine Möglichkeit nur die Library zu linken und im Fehlerfall oder bei F7 trotzdem im Source zu stehen? :stupid:

Mavarik

[Stevie]

Zitat:

Zitat von Mavarik (Beitrag 1273444)

Oder habe ich da etwas falsch verstanden, gibt es eine Möglichkeit nur die Library zu linken und im Fehlerfall oder bei F7 trotzdem im Source zu stehen? :stupid:

Für sowas gibt's DCUs mit Debug Informationen. ;)

[mquadrat]

Aber das wird mit dem neuen Package-Manager ja alles besser :-)

[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?

[Dejan Vu]

Zitat:

Zitat von Stevie (Beitrag 1273453)

Für sowas gibt's DCUs mit Debug Informationen. ;)

Wie, und damit kann ich dann auch in die Quellen reinhüpfen, um schrittweise auszuführen, ohne alles kompiliert zu haben? Sollte ich vielleicht doch mal das Handbuch lesen? Wenigstens ein einziges Mal? :gruebel:

[Uwe Raabe]

Zitat:

Zitat von Dejan Vu (Beitrag 1275221)

Zitat:

Zitat von Stevie (Beitrag 1273453)

Für sowas gibt's DCUs mit Debug Informationen. ;)

Wie, und damit kann ich dann auch in die Quellen reinhüpfen, um schrittweise auszuführen, ohne alles kompiliert zu haben? Sollte ich vielleicht doch mal das Handbuch lesen? Wenigstens ein einziges Mal? :gruebel:

Ja, sowas hilft gelegentlich...

Es sind zwei Dinge zu beachten:

1. Compilieren mit Debug-DCUs
2. In den Bibliotheks-Optionen muss der Pfad zu den Sourcen in Suchpfad stehen

Wohlgemerkt: Suchpfad (das ist wo der Debugger sucht) nicht Bibiothekspfad (das ist wo der Compiler sucht)!

[jaenicke]

Zitat:

Zitat von ventiseis (Beitrag 1275194)

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:

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