Maßnahmen zum Speicherverbrauch minimieren

[Sir Rufo]

Eigentlich brauchst du in deinem Projekt ja gar nicht viel ändern.

Du musst nur in dem Name-Setter eine Logik einbauen, die den String cached, bzw. den String aus dem Cache verwendet.

Dann bleibt deine Anwendung wie sie ist und trotzdem verbrennt die keinen Speicher.

So könnte dann ein StringCache aussehen

Delphi-Quellcode:

unit Common.StringCache;

interface

uses
  System.Generics.Collections,
  System.Generics.Defaults,
  System.SysUtils;

type
  IStringCache = interface
    [ '{BDD29CD1-319F-43AF-B0EE-1C7AE5E66AEC}' ]
    function Get( const AValue: string ): string;
    procedure Reset( var AValue: string );
  end;

  TStringCache = class( TInterfacedObject, IStringCache )
  private
    FLock: TObject;
    FDict: TDictionary<string, string>;
    function Get( const AValue: string ): string;
    procedure Reset( var AValue: string );
  public
    constructor Create;
    destructor Destroy; override;
  private
    class var _Default: IStringCache;
    class constructor Create;
  public
    class function Default: IStringCache;
  end;

implementation

{ TStringCache }

constructor TStringCache.Create;
begin
  FLock := TObject.Create;
  inherited Create;
  FDict := TDictionary<string, string>.Create;
end;

class constructor TStringCache.Create;
begin
  TStringCache._Default := TStringCache.Create;
end;

class function TStringCache.Default: IStringCache;
begin
  Result := _Default;
end;

destructor TStringCache.Destroy;
begin
  FreeAndNil( FDict );
  FreeAndNil( FLock );
  inherited;
end;

function TStringCache.Get( const AValue: string ): string;
begin
  TMonitor.Enter( FLock );
  try
    if not FDict.TryGetValue( AValue, Result ) then
    begin
      FDict.Add( AValue, AValue );
      Exit( AValue );
    end;
  finally
    TMonitor.Exit( FLock );
  end;
end;

procedure TStringCache.Reset( var AValue: string );
begin
  AValue := Get( AValue );
end;

end.

und das sind die Änderungen in deinem Beispiel-Projekt

Delphi-Quellcode:

uses
  Common.StringCache;

{ TNameObject }

procedure TNameObject.set_Name( const Value: string );
begin
  // fName := Value;
  fName := TStringCache.Default.Get( Value );
end;

procedure TNameObject.set_Name_( Value: string );
begin
  // fName := Value;
  fName := TStringCache.Default.Get( Value );
end;

{ TBusinessObjectString }

procedure TBusinessObjectString.set_Name( const Value: string );
begin
  // fName := Value;
  fName := TStringCache.Default.Get( Value );
end;

procedure TBusinessObjectString.set_Name_( Value: string );
begin
  // fName := Value;
  fName := TStringCache.Default.Get( Value );
end;

und schwupps ist der Speicherverbrauch überall gleich. ;)

[stahli]

Im Grunde stimmt das. Ich werde aber aus anderen Gründen aber die Interface-Lösung nutzen, da die einfachen Strings nicht reichen.

Meine Erkenntnisse:

- Das Zuweisen von String-Vatiablen zueinander verbraucht nur einmal Speicherplatz.
- Der Speicherplatz wird freigegeben, wenn es keine Referenzen mehr darauf gibt.
- (Die Speicherverwaltung von Strings entspricht heute quasi der von Interfaces)
- Zuweisung von Texten

Delphi-Quellcode:

StringA := 'Text'

und

Delphi-Quellcode:

StringB := 'Text'

belegt zwei mal Speicherplatz

Zunächst wusste ich von der Speicheroptimierung gar nichts.
Dann hatte ich die Hilfe so verstanden, dass "gleiche Texte" speichertechnisch referenziert werden (also der letzte Anstrich auch nur einmal Speicher belegt - was durch den Einsatz eines Dictionarys grundsätzlich ja auch möglich wäre, wie der Sir zeigt).
Jetzt liege ich wohl zwischen beiden Extremen richtig. :-)


Dann hielt ich es bezüglich der Speicherverwaltung für möglich, dass es einen Unterschied machen könnte, ob Strings als Funktionsparameter als var oder const übergeben werden. Das ist aber scheinbar nicht so.


Die Hilfe ist zwar bezüglich der Strings sehr umfangreich. Ich kann trotzdem nicht alles richtig nachvollziehen.
Kann aber durchaus an mir liegen. :oops:


Mal noch etwas anderes: Die Fragen
- Wieviel Speicherplatz habe ich noch, bis ein OutOfMemory kommt?
- Wieviel Speicherverbrauch meiner Anwendung würde der TaskManager ausgeben?
lassen sich nicht beantworten - oder?
Ich habe ein paar Diskussionen gefunden, bin aber nicht ganz schlau draus geworden - außer, dass es wohl nicht geht.

[Mavarik]

hmm hab ich jetzt was falsch verstanden?

10.000.000 Namecount & 10.000.000 BusinessCount sagt dein Programm

1. Test: (Name 6611715)
2. Test: (Name 4062733)
3. Test: (Name 2331856)

???

[stahli]

Sorry, das hätte ich noch erklären müssen.

Durch die Auswahl in der RadioGroupBusiness werden entsprechend viele Businessobjekte erzeugt und die Namen jeweils zufällig zugewiesen.
Dann werden die Namen ausgelesen (damit ich auch mal einen Zugriff darauf habe) und einer Stringvariablen zugewiesen.
Der letzte (zufällige) Wert wird dann einfach angezeigt.

Da ist also nicht weiter aussagekräftig und soll lediglich die Benutzung der Strings simulieren.
Durch Änderung des Wertes erkennt man außerdem, dass das Programm zumindest etwas ausgeführt hat.

[freimatz]

Zitat:

Zitat von stahli (Beitrag 1309031)

WENN man viele Daten in Objekten halten will ist es nicht schlecht, die Datenspeicherung etwas zu optimieren.

Nein. Nein. Nein.
http://ccd.ralfw.domainfactory-kunde..._Optimierungen

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

Natürlich ist es gut nichts überflüssiges im Speicher zu haben. Jede weitere Massnahmen macht den Code nur schwerer Lesbar und verhindert weitere Optimierungen.

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

Zitat von freimatz (Beitrag 1309637)

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:

Zitat von idefix2 (Beitrag 1309661)

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:

Zitat von idefix2 (Beitrag 1309661)

Zitat:

Zitat von freimatz (Beitrag 1309637)

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) :stupid:

Mavarik

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

[BUG]

Zitat:

Zitat von Mavarik (Beitrag 1309663)

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.

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