Speicherverbrauch stark gewachsen

[Ralf22]

Hallo zusammen,

ich habe großes Delphi Projekt von XE2 auf XETokyo (Update1) umgestellt. Die Anwendung läuft mittlerweile stabil, aber jetzt ist mir aufgefallen, dass sich der Speicherbedarf (Taskmanager) mehr als verdoppelt hat.
Hat jemand eine Idee was die Ursache dafür sein könnte?

Der Quellkode ist zu ca. 95% gleich, es gab keine Funktionserweiterungen, nur Anpassungen damit der Quellkode übersetzt werden konnte, dennoch ist der Speicherbedarf von 300MB auf 600MB gestiegen.

Vielen Dank für Eure Ideen.

Gruß Ralf

[Zacherl]

Ist

Delphi-Quellcode:

ReportMemoryLeaksOnShutdown

an, um schonmal ein generelles Memory Leak auszuschließen?

[Edelfix]

Es ist wahrscheinlich der Speicherbedarf der IDE gemeint. Bei uns ist es aufgefallen bei der Migration von XE nach XE7 (wir machen kleine Schritte). Der Arbeitsspeicher Verbrauch geht auf 40 bis 50% bei 8GB und die CPU Auslastung auf 30% bei 4 Kern und die DIE hängt ewig bis sie wieder bedienbar wird. Keine Ahnung was das ist.

[Glados]

Zitat:

Die Anwendung läuft mittlerweile stabil, aber jetzt ist mir aufgefallen, dass sich der Speicherbedarf (Taskmanager) mehr als verdoppelt hat.
Der Quellkode ist zu ca. 95% gleich - dennoch ist der Speicherbedarf von 300MB auf 600MB gestiegen.

Ich denke er meint eher die Anwendung und nicht die IDE.

[Ralf22]

Ja ReportMemoryLeaksOnShutdown ist schon geprüft worden, das ist es nicht, die Leaks wären ja auch in XE2 da.

Speicher des Programms ist gemeint, nicht IDE.
Von der instabilen XE7 IDE habe ich schon gehört, da gibt es einen Workaround (DLLs löschen) einfach mal suchen, ich habe kein XE7

Danke

[Bernhard Geyer]

Schon mal

{$WEAKLINKRTTI ON}

in der .dpr-Datei ergänzt.
Und die ganzen Debug-Optionen? Nicht das das Update der dproj-Dateien du eine Release-Version (ohne Debug-Infos) mit einer Version mit Debug-Infos vergleichst.

[Ralf22]

Die Debug und RTTI Optionen beeinflussen die Exe und Dll Datei Größen, aber nicht den Speicherverbrauch zur Laufzeit(oder nur minimal).

Leider ist das auch keine Erklärung für das Verhalten.

[Luckie]

Interessant wären jetzt folgende Dinge:
- Ist das nur bei diesem Projekt so?
- Liegt es eventuell an Fremdkomponenten?
- Können andere Nutzer, die umgestiegen sind, das bestätigen?
Mit den Fragen kann man das eventuell etwas eingrenzen.

[JanWe]

grüß Euch..

Speicher ist angewachsen?

Irrelevant.

Speicher ist soooo billig geworden.

ob jetzt bei Delphi ein HalloWelt.exe 181 Kb (Delphi 4) oder aktuell 23 MB (2,4 MB ohne Debuginfos) hat... vööööölich irrelevant.

(Im Speicher verbrauchen die heute auch nur 20 MB statt früher 10 MB.) Man hat's doch.

Es zählt allein der Code. der sooo viel sicherer geworden ist.

Hör (les) ich ja immer.
Aber darf ich ja nicht schreiben.

Hachja.
__
Naja, bleiben wir mal wieder ernst...
OK, da werden ja vielleicht auch ne Menge Daten in den RAM geladen.
Was für Daten? Nur Code? Oder Datenstrings?
Oder wie werden die verwaltet? mit einer Datenbank?

eine nicht-provokative, aber wichtige Frage: Ihr habt das ganze damals auf einem 32 bit System compiliert?
oder auch schon 64 Bit?
und dann als was 32 /64 Bit?

Aber WAs ist das auch für ein Programm?
Was lädt es noch alles in den RAM - PNG-Resourcenpics, die als Bitmap-Grafiken aufgrund anderer VCL-Routinen entpackt werden?
Oder ist das nur Code?
Oder nur die Libs?
ist das für den Grafik-Bereich?
Es gibt von Sysinternals (heute Microsoft-Sub-Firma) vmmap.exe, damit kann man genauer lokalisieren, welche Arten von Speicher belegt werden. (Grafik, DLLs, etc.)

ab wann tritt der Speicherverbrauch auf?
Direkt nach dem Start des Programms.exe oder ein wenig später? (nachdem ein paar Functions durchlaufen worden sind?)

[Glados]

Zitat:

Speicher ist soooo billig geworden.

Falsch gedacht. Aufgrund der immens hohen Nachfrage von Speichermodulen (flüchtiger Speicher) im asiatischen Raum ist Arbeitsspeicher teurer geworden und nicht billiger.