Maßnahmen zum Speicherverbrauch minimieren

**idefix2**

Das ist in dieser Pauschalierung nicht richtig und von den Autoren wohl auch nicht so gemeint.
Optimierungen, mit denen Daten "künstlich" zusammengepresst werden, um Speicherplatz zu sparen, sind meistens schlecht, und meistens gibt es bessere Möglichkeiten zur Optimierung, die auf einer anderen Ebene laufen, das ist richtig (wenn es in einer Property mit Getter und Setter sauber gekapselt ist, muss aber nicht einmal das schlecht sein).

Datenstrukturen so zu wählen, dass nicht völlig unnötig Speicherplatz verbraten wird, kann generell nicht schaden.

Zitat von freimatz:

Umgekehrt: es ist schlecht viele Daten in Objekten halten zu wollen.

Klar. Es ist viel besser, die Daten auf der Platte zu lassen und dort zu suchen. Soll der Anwender doch warten, dafür hat er ein "besseres" Programm.

**Mavarik**

Zitat von idefix2:

Das ist in dieser Pauschalierung nicht richtig und von den Autoren wohl auch nicht so gemeint

Das sehe ich auch so... Abgesehen davon halte ich das für groben quatsch... Leider wird viel zu wenig optimiert, daher brauchen wir ja mittlerweile SSD und 3,6 GHz.

Zitat von idefix2:

Zitat von freimatz:

Umgekehrt: es ist schlecht viele Daten in Objekten halten zu wollen.

Klar. Es ist viel besser, die Daten auf der Platte zu lassen und dort zu suchen. Soll der Anwender doch warten, dafür hat er ein "besseres" Programm.

Eben... Wofür habe ich 64GB in meinem Rechner, wenn meine Software möglichst mit 640KB versucht aus zu kommen und jeden Mist von der Platte nachlädt...

Warum soll ich für 400MB ne komplizierte SQXY Datenbank an legen, wenn ich am Anfang einfach 1GB Speicher reserviere und alle Daten in einem Rutsch in einen Puffer laden kann...(Nicht auf einem Mobilen Device)

Mavarik

**BUG**

Zitat von Mavarik:

Warum soll ich für 400MB ne komplizierte SQXY Datenbank an legen, wenn ich am Anfang einfach 1GB Speicher reserviere und alle Daten in einem Rutsch in einen Puffer laden kann...

Die Entscheidung für oder gegen Datenbank ist nochmal etwas anderes, da die zusätzliche Garantien liefert als einfach nur irgendwie Zugriff auf Daten.
Nicht zu vergessen, dass man mit einer relationalen Datenbank unzähligen Personenjahren an Optimierung mit nutzt.

**freimatz**

Welche Pauschalierung meinst du? Allgemeine Regeln müssen immer pauschal sein.
Bei all dem was ich hier so rauslese, wäre es aber schon gut die Regel zu beachten.
Naürlich ist es nicht gut, wenn der Anwender warten muss. Aber ein Programm das wegen zu wenig Speicher abstürzt ist noch viel schlechter.
Und die Zeit um mit viel Aufwand vielleicht 10% rauszuholen ist besser in eine besser Logik besser investiert.
Was anderes sind Fälle in denen es um klar begrenzte Datenhaltung geht wie z.B. in der Messtechnik. Wenn es um Businessobjekte geht, trifft das m.E. nicht zu.

**stahli**

@freimatz

Ja, an der Überlegung ist schon was dran. Man muss halt abwägen, was im Einzelfall wichtiger ist. U.U. können 10% Speicherersparnis so wichtig sein, dass man dafür mehrere Wochen Arbeit für investieren würde.

Deine erste Aussage war zu unkonkret und der konnte ich auch nicht folgen.

Jetzt will ich mich nochmal selbst zitieren:

Zitat:

- Wieviel Speicherplatz habe ich noch, bis ein OutOfMemory kommt?
- Wieviel Speicherverbrauch meiner Anwendung würde der TaskManager ausgeben?

Die Fragen wären wichtig, um Abstürze zu vermeiden. So könnte das Programm entscheiden wann es anfangen muss, Daten auszulagern.
Aber offenbar gibt es da wohl keine klare Antwort drauf...

**freimatz**

Die Frage nach dem Speicher wurde gerne verdrängt. Warum es wichtig ist, was der Taskmanager anzeigt erschließt sich mir nicht. (Außer das manche Leute meinen man könne da auf Memory-Leaks schließen)
Die Frage vieviel Speicherplatz habe ich noch finde ich schon sehr wichtig. Ich glaube da aber nicht dass es keine Antwort darauf gibt, auch wenn ich sie leider auch nicht weiß.

Um den verbrauchten Speicher festzustellen benutzen wir

zusammenfalten · markieren

Delphi-Quellcode:

			class function TMemoryManager.GetApplicationMemory(): Int64;

var

  memoryState: TMemoryManagerState;

  blockState : TSmallBlockTypeState;

begin

  GetMemoryManagerState(memoryState);

  with memoryState do begin

    Result := TotalAllocatedMediumBlockSize + TotalAllocatedLargeBlockSize;

    for blockState in SmallBlockTypeStates do

      Inc(Result, blockState.AllocatedBlockCount * blockState.UseableBlockSize);

  end;

end;

Wieviel Speicher noch frei ist, sollte man doch von Windows erfahren können. Bin jetzt zu faul zum googeln.

**stahli**

@freimatz

Memory-Leaks habe ich nicht (siehe #15).

Der Taskmanager bietet einen Hinweis, wie viel Speicher die Anwendung aktuell insgesamt verbraucht. Das wäre schon mal ein Anhaltspunkt.
Ich werde demnächst mal Deine Funktion testen.

Zitat von freimatz:

Wieviel Speicher noch frei ist, sollte man doch von Windows erfahren können. Bin jetzt zu faul zum googeln.

Ich habe dazu nichts gefunden, versuche es aber später nochmal.

@Sir Rufo

Die Strings sind Nutzdaten. Als Müll würde ich die eigentlich nicht bezeichnen wollen.

**Sir Rufo**

Zitat von stahli:

@Sir Rufo

Die Strings sind Nutzdaten. Als Müll würde ich die eigentlich nicht bezeichnen wollen.

Die Strings, die die Eigenschaften beschreiben sind Meta-Informationen. Die Werte der Eigenschaften sind die Nutzdaten.

Und als Müll habe ich die nicht bezeichnet, sondern nur, dass diese Meta-Informationen den Speicher vollgemüllt haben. Um die Schuhgröße zu speichern hast du 4 Byte Nutzdaten (Double) und 20+ Byte Meta-Informationen (UnicodeString) verbraten.

**Sir Rufo**

Hier ging es aber darum, dass eine Handvoll Objekte den Speicher mit Meta-Informationen zugemüllt haben.

Vermutlich haben diese Meta-Informationen mehr Speicher verbraucht als die Nutzdaten. Das ist in meinen Augen keine Optimierung.

Wenn ich tonnenweise Speicherlecks produzieren würde, dann ist das Beseitigen auch keine Optimierung, sondern ich mache es erst dann richtig. Optimierungen fangen da an, wo man mit richtig fertig ist.

Make it work, then make it fast (and/or smart).

**BUG**

Die Frage nach dem freien Speicher ist kompliziert, da sich die Rahmenbedingungen ständig ändern können. Das fängt schon in dem Moment an, in dem jemand im Prozess, aber außerhalb der Kontrolle deines Frameworks anfängt, Speicher zu allozieren (zum Beispiel in einer DLL).

Man kann dem Framework ein konfigurierbares Limit geben, das man selbst überwacht; wenn diese Grenze bei einer Allokation überschritten würde, muss es vorher Objekte freigeben.
Das sollte man wohl auch machen, wenn eine Allokation fehlschlägt(OutOfMemory). Dabei sollte man es vermeiden, beim Freigeben Objekte anlegen zu müssen

Außerdem kann man in diesem Moment das Limit heruntersetzen.