Maßnahmen zum Speicherverbrauch minimieren

[stahli]

@BUG

Wenn Du mit "Verdrängung" meinst, dass Daten auch ausgelagert werden können (ORM/Datenbank) dann stimmt das genau.

@TiGü

Wie Bug schrieb sehe ich das eher als abstraktes Thema an. WENN man viele Daten in Objekten halten will ist es nicht schlecht, die Datenspeicherung etwas zu optimieren.
Das trifft auch zu, wenn man die Möglichkeit vorsieht, Datenmengen in eine Datenbank auszulagern.
Platz sparen ist generell schon sinnvoll, abgesehen vielleicht, wenn man weiß, dass das eigene Projekt ohnehin nur wenig Speicher verbraucht.
Ich dachte, es gäbe hier Tipps wie: bestimmte Linkeroptionen ausschalten, RTTI deaktivieren, auf Generics verzichten usw.

@Mavarik
!48

@Union
Das Projekt kennst Du ja, nur nicht den aktuellen Quelltext.
Meine Kontaktkanäle wären noch offen...

@Sir Rufo
Da ich fName: String durch fNameIntf: IInterfaceMitNamenEigenschaft ersetzt habe bin ich davon ausgegangen, dass der Speicherverbrauch deutlich zurückgeht, da es dann nur noch wenige Objekte gäbe, die die eigentlichen Namen verwalten. Auf diese würden nur noch Pointer zeigen.
Dass das Gegenteil rauskam hat mich verwundert. Aber gestern war es mir dann schon zu spät für weitere Untersuchungen.
Die Namen werden von dem benamten Objekt (Interface) über eine Funktion bereitgestellt: S := MyNamedIntf.Name; und dann lokal weiter verarbeitet.
Eigentlich sollte der String-Speicher dann ja wieder freigegeben werden, wenn der lokale Scope verlassen wird.
Ich werde heute Abend Dein Demoprojekt mal umbauen (TNameObject + INameInterface) und damit testen.
Ich will ja auch verstehen, wie das zusammenhängt. Bisher hatte ich noch keinen Bedarf an solchen Optimierungen und daher keine entsprechenden Kenntnisse.

Ich melde mich dann wieder...

[idefix2]

Wie lange können deine Namen maximal werden, wie lange sind sie im Durchschnitt, und wieviele verschiedene Namen gibt es?
Von den Fragen hängt wohl ab, in welcher Richtung da Optimierungen zielführend sein können.

[stahli]

So, mal ein Testprojekt (XE3-Projekt + EXE) anbei.

Man kann erst mal mehrere Namen-Objekte erzeugen und dann mehrere Business-Objekte (bzw. Interfaces), denen dann Namen zugewiesen werden.

Den Zuweisungsmodus kann man auswählen. Man kann die Stringvariable übergeben oder das Namenobjekt oder einen neuen Text.
Jeden Modus einmal mit const- und var-Parameter.

Das Zuweisen eines neuen Textes erzeugt erwartungsgemäß einen höheren Speicherbedarf.
Stringreferenz und Interfacereferenz sind gleichermaßen platzsparend.
Ob var- oder const-Parameter spielt keine Rolle.

Jetzt werde ich mein Projekt nochmal entsprechend überarbeiten.

[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 StringA := 'Text' und 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.


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 von stahli:

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