SetLength -> Zu wenig Arbeitsspeicher?

[AJ_Oldendorf]

Ich werde mir das mal angucken mit den Speicherlecks und Speichermap.
Vielleicht komm ich da ja dahinter...
Glaube aber wirklich, dass es wirklich nur an der Fragmentierung liegt da laut TaskManager eben diese 2GB Grenze gar nicht erreicht wird von der Anwendung!

Viele Grüße
Alex

[Neutral General]

Also ich denke wenn im Taskmanager weniger als 2GB angezeigt werden (wie viel sinds denn ca.?), dann sind es auch MIT Datenfragmentierung weniger als 2GB und das Problem liegt nicht an der Menge des Arbeitsspeichers, sondern wahrscheinlich wie ich schon vermutet habe, dass der PAnsiString auf Müll zeigt oder du versehentlich eine zu große Zahl an SetLength übergibst.. Z.B. durch eine uninitialisierte Variable o.ä.

[angos]

Hi,

Zu der 2GB/4GB Problematik hier ein vielleicht noch interessanter Artikel:

Klick mich

Ich würde auch eher auf einen Fehler in deiner Programmierung tippen, wie auch schon von Neutral General erwähnt wurde, oder deine Anwendung benötigt tatsächlich soviel, was dann darauf hinausläuft, dass dein Konzept überarbeitet werden sollte

Achja, was mir mal aufgefallen war:

SetLength(ArrayEinesTyps, 2);

rufe ich das einmal auf, so wird der Speicher einmal für zwei ArrayEintraege belegt.
Rufe ich das nochmals auf, so wird ungenutzter Speicher dafür neu belegt, der alte aber nicht freigegeben, laut Taskmanager bleibt der RAM genutzt.

Lediglich SetLength(ArrayEinesTyps, 0); gibt den Speicher tatsächlich wieder frei.


Seit dem verusche ich entweder, die Array-Längen einmal im Programm definieren zu können, oder Objektlisten zu nutzen.


Gruß

[Neutral General]

@angos:

Der Artikel ist zwar interessant, aber meiner Meinung nach nicht relevant. Es geht ja hier um virtuellen Speicher. Und bei virtuellem Speicher sind haben die im Artikel genannten Beschränkungen keine Bedeutung.

[xZise]

Moin,

Zitat von angos:

[...]Achja, was mir mal aufgefallen war:

SetLength(ArrayEinesTyps, 2);

rufe ich das einmal auf, so wird der Speicher einmal für zwei ArrayEintraege belegt.
Rufe ich das nochmals auf, so wird ungenutzter Speicher dafür neu belegt, der alte aber nicht freigegeben, laut Taskmanager bleibt der RAM genutzt. [...]

Bist du dir da sicher? Ich behaupte mal so, dass sogut wie keiner das alte Array "freigibt". Und MemoryLeaksOnShutdown meldet da ja auch nichts. Aber ich teste es einfach mal.

So, also mit folgenden Code bleibt der RAM Verbauch konstant bei 44 MiB (und dabei ist das Array selber schon ~ 40 MB groß):

Delphi-Quellcode:

type
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private
    x : array of Integer;
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
begin
  SetLength(x, 10000000);
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
  while True do
    Button1Click(nil);
end;

Übrigens wegen der Defragmentierung: Stimmt, naja wer sagt da das man x64 nicht braucht Da kann es einen egal sein (sofern die Anwendungd das nutzt).

MfG
Fabian

[himitsu]

Hier mal das reine Defragmentierungsproblem

Delphi-Quellcode:

program Project8;

{$APPTYPE CONSOLE}

uses
  Types, Windows, SysUtils;

function GetMemSize: Integer;
var
  ms: TMemoryStatusEx;
begin
  ms.dwLength := SizeOf(ms);
  GlobalMemoryStatusEx(ms);
  Result := ms.ullTotalVirtual - ms.ullAvailVirtual;
end;

var
  i: Integer;
  a: TIntegerDynArray;

begin
  ReportMemoryLeaksOnShutdown := True;
  try
    i := 1;
    while True do begin
      WriteLn(Format('a: %0.n     mem: %0.n', [i / 1, GetMemSize / 1]));
      SetLength(a, i);
      i := i * 2;
    end;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
  ReadLn;
end.

[]add

Delphi-Quellcode:

while True do
  TForm1.Create(self);

ist noch besser, denn es erzeugt kein "echtes" Speicherloch, da kurz vor Programmende der Owner für's Aufräumen sorgt,
aber wärend des Programmablauf's wirkt sich dieses wie ein Speicherleck aus.

[xZise]

Zitat von himitsu:

[...]

Delphi-Quellcode:

while True do
  TForm1.Create(self);

ist noch besser, denn es erzeugt kein "echtes" Speicherloch, da kurz vor Programmende der Owner für's Aufräumen sorgt,
aber wärend des Programmablauf's wirkt sich dieses wie ein Speicherleck aus.

Und wann soll der Owner zum Aufräumen kommen

MfG
Fabian

[himitsu]

Nach der Exception läuft das, wenn man es z.B. in einen Button-OnClick ausführt, in den VCLeigenen Ereignismethodenaufruf-Try-Except-Schutzblock.

Wenn man danach dann die Hauptform schließt, dann nimmt sie alles mit, sobald die VCL Application freigibt und dieses die Hauptform mitnimmt.


Alles in OnCreate der Form1/Hauptform und bei der Exception nehmen sich die Objekte selber mit (Exception im Constructor löscht das Objekt wieder)
> hier braucht man nichtmal die Schleife, da alles rekursiv

[angos]

Zitat von xZise:

Moin,

Zitat von angos:

[...]Achja, was mir mal aufgefallen war:

SetLength(ArrayEinesTyps, 2);

rufe ich das einmal auf, so wird der Speicher einmal für zwei ArrayEintraege belegt.
Rufe ich das nochmals auf, so wird ungenutzter Speicher dafür neu belegt, der alte aber nicht freigegeben, laut Taskmanager bleibt der RAM genutzt. [...]

Bist du dir da sicher? Ich behaupte mal so, dass sogut wie keiner das alte Array "freigibt". Und MemoryLeaksOnShutdown meldet da ja auch nichts. Aber ich teste es einfach mal.

[...]

MfG
Fabian

Hi,

ich hatte dieses Problem öfters mit Record-Arrays kann dir aber auch so nicht sagen, wie das Problem genau zustande gekommen ist.
Ich nutze halt seit dem, wenn ich noch mit arrays arbeite zusätzlich einfach das SetLength(x, 0); mittlerweile aus Gewohnheit.
Vielleicht liegt es an den Records oder an bestimmten Datentypen im Record?!

Gruß
angos

[AJ_Oldendorf]

wie hast du das festgestellt, dass der Speicher laut TaskManager nicht freigegeben wird?
Ist dies nur bei einem Array der Fall oder bei jedem Typ?

Viele Grüße
Alex