Speicherverbrauch stark gewachsen

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