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.

[Zacherl]

Zitat:

Zitat von Glados (Beitrag 1382313)

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.

Ich befürchte, hier bist du auf Sarkasmus reingefallen.

[Ralf22]

In beiden benutzten Delphi Versionen wird eine 32 bit Anwendung erzeugt.
Bei anderen kleineren Projekten ist der Unterschied im Speicherverbrauch nicht so dramatisch, diese Anwendungen benötigen ca. 20% mehr Speicher, wenn diese mit D10.2 Tokyo übersetzt wurden.
Das Projekt, bei dem der Speicherverbrauch um 50% ansteigt, benutzt intern einige Stringlisten, die bis zu 50.000 Einträge haben und 2 ClientDataSets mit bis zu 100.000 Records. Zumindest sind das meine Hauptverdächtigen für dieses Problem. Es gibt auch noch 3 TList Ableitungen deren Items Packed Records sind, auch jeweils mit ca. 50.000 Items. Das Projekt ist schon 20 Jahre alt !

[mikhal]

Kannte XE2 bereits Unicode - bzw. waren die XE2-Strings bereits Unicode oder waren es ANSI-Strings? Wenn es ANSI-Strings waren, kannst du grob eine Verdopplung des Speichers für deine Stringlisten annehmen.

Grüße
Mikhal

[Bernhard Geyer]

Zitat:

Zitat von mikhal (Beitrag 1382563)

Kannte XE2 bereits Unicode - bzw. waren die XE2-Strings bereits Unicode oder waren es ANSI-Strings? Wenn es ANSI-Strings waren, kannst du grob eine Verdopplung des Speichers für deine Stringlisten annehmen.

Grüße
Mikhal

Ab D2009 ist String = UnicodeString

[Ralf22]

Beide Compilate (XE2, XE10.2) verwenden Unicode strings.

[Zacherl]

Kannst ja mal die Größen der

Delphi-Quellcode:

packed record

s vergleichen. Vielleicht haben sich hier die beinhaltenden Datentypen verändert. Was mir auch in den Sinn kam: Wenn du Konstrukte der Form

Delphi-Quellcode:

var A: array[TIrgendeinEnum] of TIrgendwasGrosses

hast und das Enum einige neue Elemente bekommen hat, könnte das auch zu mehr Verbrauch führen. Kann man leider nur spekulieren.

[Der schöne Günther]

Könnte man nicht mit FastMM sich die Anzahl der Speicher-Reservierungen und was die jeweils an Speicher fressen ansehen? Damit könnte man doch eigentlich die notwendigen Rückschlüsse ziehen, ob es das ClientDataSet, die Record-Liste oder was anderes ist.

Lesestoff:
1. http://www.thedelphigeek.com/2012/06...-purposes.html
2. https://stackoverflow.com/questions/14390934/
3. https://github.com/pleriche/FastMM4/...sage%20Tracker

[Ralf22]

Das Problem ist gelöst, peinlicherweise kein Delphi-Problem, das Programm benutzt einige C-Treiber. Einer der C-Treiber verursacht den hohen Speicherverbrauch. Das XE10 Programm benutzt jetzt nur noch ca. 3% mehr RAM-Speicher als die XE2 Exe.
Danke an alle.

[Benedikt Magnus]

Wenn man fragen darf, wie hast du das ermitteln können und wie hat der C-Treiber plötzlich beim Umstieg den Speicherverbrauch so ansteigen lassen?

[Ralf22]

Mit dem Debugger, nach dem Aufruf einer Funktion in der Treiber DLL ist der Speicherverbrauch stark angestiegen. Da war ein Überlauf bei der Berechnung der Größe für einen Pufferspeicher.
Wir hatten schon öfters nicht initialisierte Stack Variablen die über Jahre immer zufälliger Weise mit Werten versehen waren, die keine Probleme machten. Bei einer neuen Delphiversion fällt das dann plötzlich auf und man findet einen uralten Bug.
z.B. gibt Delphi keine Warnung aus, wenn eine Variable von einen Mengentypen nicht initialisiert wird. Zumindest war das an der Stelle so, ich weiss nicht ob das generell so ist.

[Der schöne Günther]

Pff, Delphi zeigt noch nicht einmal eine Warnung an wenn du einen Integer in ein Byte stecken willst oder einen nicht initialisierten Record verwendest. Delphi sieht das alles etwas lockerer, man muss ja nicht alles so ernst nehmen :|

Delphi-Quellcode:

type
   TMyRecord = record
      value: Integer;
   end;

procedure p();
var
   myRecord: TMyRecord;
   myInteger: Integer;
begin
   WriteLn(myRecord.value); // << Keine Warnung
   WriteLn(myInteger);
end;