Mein Programm ist Arbeitsspeicher hungrig..

[Dalai]

Da werden einige Variablen Objekte (Krümelkackermode: "Instanz einer Klasse") erzeugt, aber nicht wieder freigegeben, vor allem in den Funktionen BuiltIDList und BuiltIDListEx. Da letztere noch dazu in einer Schleife x-fach aufgerufen wird, dengeln dann mehrere Objekte von http und ssl im Speicher rum -> Speicherleck. Dagegen hilft einerseits konsequentes Einhalten von Coding-Richtlinien* und andererseits ReportMemoryLeaksOnShutdown oder andere Tools zum Finden von Speicherlecks.

[EDIT] Da gibt's sogar noch weitere Objekte in den anderen Funktionen, die nicht wieder freigegeben werden. [/QUOTE]

*) Man muss sich einfach selbst zwingen, sauber zu schreiben, d.h. sofort beim Erzeugen eines Objekts das Freigeben gleich mit hinschreiben, bevor man sich an den eigentlichen Code zum Verwenden des Objekts macht. Mal ein Beispiel: erst dieses Rumpfgerüst schreiben:

Delphi-Quellcode:

objekt:= TKlasse.Create;
try
  // Code
finally
  objekt.Free
end;

und dann erst im

Delphi-Quellcode:

try

-Block den eigentlichen Code hinzufügen. So gehe ich jedenfalls vor.

MfG Dalai

PS: Übrigens ist der Name BuiltIDList falsch, es müsste BuildIDList heißen, denn das Teil wird erst aufgebaut und wurde nicht bereits erzeugt (built = Vergangenheitsform von build).

[Sir Rufo]

Entwickelst du für die Mobile Plattforms oder warum gibts du da einige Sachen nicht frei?

Prüfe deinen Code - überall wo du Instanzen erzeugst musst du die irgendwann auch wieder frei geben. Das sehe ich aber nicht bei allen Instanzen ...

[Cubysoft]

Ja das ist korrekt. Werde das nochmal überarbeiten. Danke

Vielen Dank. Es lag an den vielen Instanzen von IDHttp und dem SSL Teil. Funktioniert jetzt bestens mit 5MB RAM-Verbrauch. Records und Variablen müssen nicht freigegeben werden oder?

[Dalai]

Zitat:

Zitat von Cubysoft (Beitrag 1302058)

Records und Variablen müssen nicht freigegeben werden oder?

Kann man so nicht sagen. Eine Variable und auch Records können Objekte beinhalten. Schließlich heißt es ja z.B.

Delphi-Quellcode:

var sl: TStringList;

Und Objekte, die man erzeugt, muss man auch wieder freigeben.

MfG Dalai

[Popov]

Zitat:

Zitat von Cubysoft (Beitrag 1302058)

Records und Variablen müssen nicht freigegeben werden oder?

Solange Records nur normale Variablen enthalten, also z. B. keine Objekte, nein, in den Fall muss man sie nicht freigeben.

[hoika]

Hallo,
ich würde noch packend Record schreiben.

Für Speicherlecks werfe ich noch FastMM4 rein..


Heiko

[himitsu]

Packed wird hier nichts ändern und bei aktiv genutzten Records im Speicher ist wowas es etwas ungünstiger.

Vorner der 4 Byte Pointer und dahinter eine gute Anzahl an Bytes, womit am Ende alles praktisch schon gepackt ist, da keine Leerstellen entstehen
und es sind sogar so viele Bytes (Boolean), daß der Record voll ist. (vielfaches von 4)

Und dann ist das Array mit den Records eh nichtmal 2 MB groß.
Wie hier welche entdeckt haben, liegt das Problem ja ganz wo anders. (Speicherlecks)

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1302078)

Packed wird hier nichts ändern und bei aktiv genutzten Records im Speicher ist wowas es etwas ungünstiger.

Vorner der 4 Byte Pointer und dahinter eine gute Anzahl an Bytes, womit am Ende alles praktisch schon gepackt ist, da keine Leerstellen entstehen
und es sind sogar so viele Bytes (Boolean), daß der Record voll ist. (vielfaches von 4)

Und dann ist das Array mit den Records eh nichtmal 2 MB groß.
Wie hier welche entdeckt haben, liegt das Problem ja ganz wo anders. (Speicherlecks)

Nööö jedes Byte wird aligned daher
{$A1}

Und NATÜRLICH keinen Logstring nehmen.... Wie oft steht da der gleiche String drin?

[himitsu]

Bytes sind nie Aligned, bzw. immer an 1 ausgerichtet, egal ob mit oder ohne Packed.

{$ALIGN} gibt nur die maximale Ausrichtung an und kleineren Typen werden immer an ihrer eigenen Größe ausgerichtet.

Zitat:

Wire oft steht da der gleiche String drin?

Ist egal, solange die Strings nicht aus der selben Quelle kommen (Kopie des selben Strings), belegt jeder leider seinen eigenen Speicher.
Die Strings werden alle "neu" erzeugt (teilweise aus einem Anderen rauskopiert) und sind demnach immer unique. (gibt standardmäßig "leider" keinen Algo, der das zusammenfasst)

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1302139)

Die Strings werden alle "neu" erzeugt (teilweise aus einem Anderen rauskopiert) und sind demnach immer unique. (gibt standardmäßig "leider" keinen Algo, der das zusammenfasst)

Und? Chars in einer großen Liste speichern und nur den Pointer auf den Start... Test ob Kombination schon existent und gleichen pointer zurück geben...