Code-Kata: Cache-Klasse. Wer produziert den besten Code

[Namenloser]

Ich geb mal meinen Senf dazu. Bin jetzt nicht wirklich glücklich über den ganzen Boilerplate-Code, aber ich kann ja auch nichts dafür, dass es keine gescheite Standardlib gibt (oder hat Delphi inzwischen eine verkettete Liste? Habe nichts gefunden).

Habe den Code nicht getestet, da ich kein Delphi mehr habe, also habe ich bestimmt irgendwo was übersehen. Aber es geht ja eher um den Ansatz, denke ich.

Ein paar Worte zu meinen Designentscheidungen:
- Ich habe es jetzt mal so interpretiert, dass es ein einfacher MRU-Cache sein soll.
- Ich prüfe nicht explizit ob die Aufrufe gültig sind (z.B. ob bei Get der Key auch wirklich existiert) und werfe daher auch keine Exceptions. Denn offensichtlich ist die Schnittstelle so angelegt, dass der Benutzer vorher selbst mit Contain prüfen soll, ob der Key existiert. Wenn die Klasse selber es dann noch mal prüfen würde, würde doppelt geprüft. Deswegen habe ich die Prüfungen nur als nur Assertions drin. Die ganze Schnittstelle ist meiner Meinung nach nicht optimal (die von TDictionary übrigens auch nicht), aber war ja so vorgegeben, also muss man das beste daraus machen.
- Edit: Achso, und falls sich jemand wundert: Ich verwende grundsätzlich (fast) nie private sondern immer protected (bis auf sehr wenige Ausnahmen, bei denen es wirklich gute Gründe gibt, die dagegen sprechen). Könnt ihr meinetwegen schlecht finden, ist mir aber egal

Delphi-Quellcode:

  { TLinkedListItem }

  TLinkedListItem<T> = class
  protected
    FValue: T;
    FPrev: TLinkedListItem<T>;
    FNext: TLinkedListItem<T>;
  public
    constructor Create;
    constructor Create(Value: T);
    property Value: T read FValue write FValue;
    property Next: TLinkedListItem<T> read FNext;
    property Prev: TLinkedListItem<T> read FPrev;
  end;

  { TLinkedList }

  TLinkedList<T> = class
  protected
    FSentinel: TLinkedListItem<T>;
    function GetFirst: TLinkedListItem<T>;
    function GetLast: TLinkedListItem<T>;
  public
    constructor Create;
    destructor Destroy; override;
    procedure InsertBefore(Item: TLinkedListItem<T>; Successor: TLinkedListItem<T>);
    function Extract(Item: TLinkedListItem<T>): TLinkedListItem<T>;
    property First: TLinkedListItem<T> read GetFirst;
    property Last: TLinkedListItem<T> read GetLast;
  end;

  { TCache }

  TCache = class
  protected type
    TKeyValuePair = record
      Key: Integer;
      Value: TObject;
    end;

    TCacheItem = TLinkedListItem<TKeyValuePair>;
    TCacheItemList = TLinkedList<TKeyValuePair>;
  protected
    FMaxSize: Integer;
    FMRU: TCacheItemList;
    FMap: TDictionary<Integer, TCacheItem>;

    function GetCurrentNumberOfElements: Integer;
    function GetSize: Integer;

    function MakePair(Key: Integer; Value: TObject): TKeyValuePair;

    procedure Bump(Item: TCacheItem);
    procedure Evict(Item: TCacheItem);
  public
    constructor Create(MaxSize: Integer);
    destructor Destroy; override;
    function Contains(ID: Integer): Boolean;
    function Get(ID: Integer): TObject;
    procedure Put(ID: Integer; Item: TObject);
    procedure Remove(ID: Integer);
    property MaxSize: Integer Read FMaxSize;
    property CurrentNumberOfElements : Integer Read GetCurrentNumberOfElements;
  end;

implementation

{ TLinkedListItem }

constructor TLinkedListItem<T>.Create;
begin
  FNext := Self;
  FPrev := Self;
end;

constructor TLinkedListItem<T>.Create(Value: T);
begin
  Create;
  Self.Value := Value;
end;

{ TLinkedList }

constructor TLinkedList<T>.Create;
begin
  FSentinel := TLinkedListItem<T>.Create;
end;

destructor TLinkedList<T>.Destroy; override;
begin
  FSentinel.Free;
end;

function TLinkedList<T>.GetFirst: TLinkedListItem<T>;
begin
  Result := FSentinel.Next;
end;

function TLinkedList<T>.GetLast: TLinkedListItem<T>;
begin
  Result := FSentinel.Prev;
end;

procedure TLinkedList<T>.InsertBefore(Item: TLinkedListItem<T>;
  Successor: TLinkedListItem<T>);
begin
  Extract(Successor);
  Item.Next := Successor;
  Item.Prev := Successor.Prev;
  Item.Next.Prev := Item;
  Item.Prev.Next := Item;
end;

function TLinkedList<T>.Extract(Item: TLinkedListItem<T>): TLinkedListItem<T>;
begin
  Item.Prev.Next := Item.Next;
  Item.Next.Prev := Item.Prev;
  Item.Prev := Item;
  Item.Next := Item;
  Result := Item;
end;

{ TCache }

constructor TCache.Create(MaxSize: Integer);
begin
  FMaxSize := MaxSize;
  FMap := TDictionary<Integer, TCacheItem>.Create;
  FMRU := TCacheItemList.Create;
end;

destructor TCache.Destroy; override;
begin
  while (NumberCurrentNumberOfElements > 0) do
    Evict(FMRU.First);
  FMRU.Free;
  FMap.Free;
end;

function TCache.GetCurrentNumberOfElements: Integer;
begin
  Result := FMap.Count;
end;

function TCache.MakePair(Key: Integer; Value: TObject): TKeyValuePair;
begin
  Result.Key := Key;
  Result.Value := Value;
end;

procedure TCache.Bump(Item: TCacheItem);
begin
  FMRU.InsertBefore(CacheItem, FMRU.First);
end;

procedure TCache.Evict(Item: TCacheItem);
begin
  FMap.Remove(CacheItem.Value.Key);
  FMRU.Extract(CacheItem);

  CacheItem.Value.Value.Free;
  CacheItem.Free;
end;

function TCache.Contains(ID: Integer): Boolean;
begin
  Result := FMap.ContainsKey(ID);
end;

function TCache.Get(ID: Integer): TObject;
var
  CacheItem: TCacheItem;
begin
  Assert(Contains(ID));

  CacheItem := FMap[ID];
  Bump(CacheItem);
  Result := CacheItem.Value.Value;
end;

procedure TCache.Put(ID: Integer; Item: TObject);
var
  CacheItem: TCacheItem;
begin
  Assert(not Contains(ID));

  if GetCurrentNumberOfElements >= FMaxSize then
    Evict(FMRU.Last);

  CacheItem := TCacheItem.Create(MakePair(ID, Item));
  FMap[ID] := CacheItem;
  Bump(CacheItem);
end;

procedure TCache.Remove(ID: Integer);
begin
  Assert(Contains(ID));
  Evict(FMap[ID]);
end;

[idefix2]

Hier mein erster Versuch.

Das Interface der Klasse habe ich bewusst etwas anders gestaltet als in der Vorgabe: Die Klasse kümmert sich sowohl umd das Nachladen von Objekten aus dem externen Speicher als auch um das externe Speichern veränderter Daten.
Dazu müssen ihr beim Create zwei Routinen übergeben werden, die das Laden und Speichern der Daten erledigen. Das Programm, das den Cache dann verwendet, holt alle Daten aus der Cache Klasse und schreibt Veränderungen auch nur in die Cache Klasse.

Für die aktuellen Cacheelemente sollte wohl zusätzlich noch eine nach dem "Hinauswurfkriterium" sortierte Liste verwaltet werden (oder sogar statt des TDictionary, aber dadurch würde das Auffinden der im Cache vorhandenen Elemente wieder langsamer), damit man nicht alle Elemente durchgehen muss, wenn ein Element aus dem Cache zu entfernen ist, um herauszufinden, welches weggehört. Eine einfache verkettete Liste, wie sie namenloser in seinem Algorithmus verwendet, bringt nicht viel, weil man dann die verkettete Liste trotzdem immer durchgehen muss, um das an Stelle des hinausgeworfenen Elements hinzukommende neue Element an der richtigen Stelle einzufügen, das ist nämlich auch nicht unbedingt am Ende der Liste.

Die gespeicherte Zugriffshäufigkeit eine Elements wird beim Entfernen des Elements aus dem Cache halbiert, damit sich uralte hohe Zugriffshäufigkeiten weniger stark auswirken.

Delphi-Quellcode:

unit CacheUnit;

interface

uses Generics.Collections;

Type
  // Callback zum Laden eines externen Objekts, wenn es noch nicht im Cache ist
  TLoadFunction = function (key: integer): TObject;
  // Callback zum externen Speichern eines Objekts
  TSaveFunction = procedure (key: integer; Obj: TObject);

  TCache = Class
  type
     TItem = record
        LastAccess: integer;
        AccessCount: integer;
        end;
  private
     FCurrentSize: Integer;
     FCache: array of TObject;
     FWeightTime: integer;
     FWeightFrequency: integer;
     FLoadObject: TLoadfunction;
     FSaveObject: TSavefunction;
     FCurrentAccess: integer;
     FAllItems: TDictionary<integer,TItem>;      // enthält Nutzungsdaten der Elemente
     FCachedItems: TDictionary<integer,integer>; // Enthält Index der Elemente im Cache

     FHitCount: integer;
     FReadCount: integer;

     function GetMaxSize: integer;
     function FindPlaceInCache: integer;
     procedure RegisterAccess(ID: integer);
     function GetHitPercentage: integer;

  public
     Constructor Create (MaxSize : Integer; WeightTime, WeightFrequency: integer;
          LoadObject: TLoadfunction; SaveObject: TSaveFunction);
     Destructor Destroy;
     Function Get (ID : Integer) : TObject;
     Procedure Put (ID : Integer; Obj : TObject);
     Property MaxSize : Integer Read GetMaxSize;
     Property CurrentNumberOfElements : Integer Read FCurrentSize;
     Property HitPercentage: integer Read GetHitPercentage;
  end;

////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
//
implementation
//
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////


constructor TCache.Create(MaxSize: Integer; WeightTime, WeightFrequency: integer;
     LoadObject: TLoadFunction; SaveObject: TSaveFunction);
begin
  inherited create;
  SetLength(FCache,MaxSize);
  FLoadObject := LoadObject;
  FSaveObject := SaveObject;
  FAllItems := TDictionary<integer,TItem>.Create;
  FCachedItems := TDictionary<integer,integer>.Create;
  FWeightTime:= WeightTime;
  FWeightFrequency:= WeightFrequency;
end;

destructor TCache.destroy;
begin
  FCachedItems.free;
  FAllItems.free;
  inherited;
end;

////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
//
// TCache.GetMaxSize und GetHitPercentage
//
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////

function TCache.GetMaxSize: integer;
begin
Result:=Length(FCache);
end;

function TCache.GetHitPercentage: integer;
begin
if FReadCount=0
then Result:=0
else Result:=FHitCount * 100 div FReadCount;
end;


////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
//
// Platz im Cache finden und nötigenfalls freimachen
//
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////

function TCache.FindPlaceInCache: integer;
var
  Key, KeyToRemove: integer;
  Worst,Kriterium: integer;
  Item: TItem;
begin
if FCurrentSize<Length(FCache) // noch Platz im Cache
then begin 
     result:=FCurrentSize; 
     inc(FCurrentSize); 
     exit 
     end;

Worst:=FCurrentAccess*FWeightFrequency;
for Key in FCachedItems.Keys do
    begin
    with FAllItems[Key] do
         Kriterium:=AccessCount*FWeightFrequency-(FCurrentAccess-LastAccess)*FWeightTime;
    if Kriterium<Worst
    then begin Worst:=Kriterium;
         KeyToRemove:=key;
         Result:=FCachedItems[key];
         end;
    end;

FCachedItems.Remove(KeytoRemove);
Item:=FAllItems[KeyToRemove];
Item.AccessCount:=Item.AccessCount div 2;
FAllItems.AddOrSetValue(KeyToRemove,Item);
end;

////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
//
// TCache.Get und Put
//
////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////

procedure TCache.RegisterAccess(ID: integer);
var
  item: TItem;
begin
  inc(FCurrentAccess);
  if FAllItems.ContainsKey(ID)
  then begin item:=FAllItems[ID]; inc(Item.AccessCount) end
  else item.Accesscount:=1;
  item.LastAccess:=FCurrentAccess;
  FAllItems.AddOrSetValue(ID,Item);
end;

function TCache.Get(ID: Integer): TObject;
var
  idx: integer;
begin
  inc(FReadCount);
  if FCachedItems.TryGetValue(ID, idx)
  then inc(FHitCount)
  else begin
       idx:=FindPlaceInCache;
       FCache[idx]:=FLoadObject(ID);
       FCachedItems.Add(ID,idx);
       end;
  RegisterAccess(ID);
  Result:=FCache[idx];
end;


procedure TCache.Put(ID: Integer; Obj: TObject);
var
  idx: integer;
begin
  FSaveObject(ID, Obj);
  inc(FCurrentAccess);
  if not FCachedItems.TryGetValue(ID, idx)
  then begin
       idx:=FindPlaceInCache;
       FCachedItems.Add(ID,idx)
       end;
  FCache[idx]:=Obj;
  RegisterAccess(ID);
end;

end.

[Namenloser]

Zitat von idefix2:

Für die aktuellen Cacheelemente sollte wohl zusätzlich noch eine nach dem "Hinauswurfkriterium" sortierte Liste verwaltet werden (oder sogar statt des TDictionary, aber dadurch würde das Auffinden der im Cache vorhandenen Elemente wieder langsamer), damit man nicht alle Elemente durchgehen muss, wenn ein Element aus dem Cache zu entfernen ist, um herauszufinden, welches weggehört. Eine einfache verkettete Liste, wie sie namenloser in seinem Algorithmus verwendet, bringt nicht viel, weil man dann die verkettete Liste trotzdem immer durchgehen muss, um das an Stelle des hinausgeworfenen Elements hinzukommende neue Element an der richtigen Stelle einzufügen, das ist nämlich auch nicht unbedingt am Ende der Liste.

Hö? Da wird nichts durchgegangen. Es gibt einen Pointer auf das erste und auf das letzte Element. Einfügen und Löschen passiert in O(1).

[idefix2]

Ich spreche von meinem Algorithmus.
Du hast einen einfachen MRU (laut inzwischen modifizierter Vorgabe, im Eingangspost war etwas anderes verlangt) implementiert, da braucht man das natürlich nicht.

[Dejan Vu]

Zitat von idefix2:

Das Interface der Klasse habe ich bewusst etwas anders gestaltet als in der Vorgabe

Wieso hältst Du dich nicht an die Vorgabe? Wieso soll sich ein Cache um das Schreiben kümmern? Wieso soll er Statistiken pflegen?

Durchgefallen.

Im Ernst: Sollen wir für deine Sonderklasse extra eigene Test- und Prüfroutinen schreiben?


Schreib Deine doch bitte um, dann kann man die mit den MRU-Ansätzen vergleichen. Dein Algorithmus ist wirklich sehr interessant.

Ein Tipp bezüglich der function TCache.FindPlaceInCache: integer; : Du rennst mit einer For-Schleife durch die Liste? Das ist jetzt aber nicht so sonderlich performant, denn ein Cache verwaltet i.a. Millionen von Elementen.
Diese Routine wird bei jedem Cache-Aufruf einmal komplett durch alle Elemente laufen. Das kannst Du mit einer Priority-Queue (bzw. einem Baum) viel effizienter Lösen. Der wird bei jedem Zugriff sortiert bzw. mit wenigen Handgriffen angepasst, sodass dein 'worst element' immer automatisch 'oben' ist. Aber die Implementierung ist natürlich ungemein komplexer.

Zitat von Namenloser:

Ein paar Worte zu meinen Designentscheidungen:
- Ich prüfe nicht explizit ob die Aufrufe gültig sind (z.B. ob bei Get der Key auch wirklich existiert) und werfe daher auch keine Exceptions. Denn offensichtlich ist die Schnittstelle so angelegt, dass der Benutzer vorher selbst mit Contain prüfen soll, ob der Key existiert....

Gut gesehen.

Zitat:

...Die ganze Schnittstelle ist meiner Meinung nach nicht optimal...

Gegenvorschlag?

Zitat:

Ich verwende grundsätzlich (fast) nie private sondern immer protected (bis auf sehr wenige Ausnahmen, bei denen es wirklich gute Gründe gibt, die dagegen sprechen).

Welche Gründe sprechen gegen private Felder? Properties sehe ich ein, aber Felder sollten so strict private sein, wie es nur geht.
Ich deklariere Felder immer privat (außer bei DTO) aber den Zugriff per Property als protected. Vermutlich ist das das Gleiche, aber mit mehr Tipparbeit verbunden.

Das 'MakePair' würde ich dem TKeyValuePair als Create spendieren. Gehört -finde ich- dorthin.

Delphi-Quellcode:

// function TCache.MakePair(Key: Integer; Value: TObject): TKeyValuePair;
// begin
//   Result.Key := Key;
//   Result.Value := Value;
// end;

constructor TKeyValuePair.Create(aKey: Integer; aValue: TObject)
begin
  Self.Key := aKey;
  Self.Value := aValue;
end;

Das Freigeben des Cache-Items gehört (finde ich) in den Destruktor des TCacheItem.... Aber wieso gibst Du dort auch das 'Value' frei? Das ist doch das zu cachende Objekt? Damit hat doch der Cache nix am Hut. Oder hab ich mich verlesen?

Delphi-Quellcode:

procedure TCache.Evict(Item: TCacheItem);
begin
  ...
  CacheItem.Value.Value.Free; // <<<--- Mööp, ich glaube, da ist ein Value. zu viel
  CacheItem.Free;
end;

Hier würde ich zwei zusätzliche kleine Methoden draus machen (Lesbarkeit, Clean Code).

Delphi-Quellcode:

// procedure TCache.Put(ID: Integer; Item: TObject);
// var
//   CacheItem: TCacheItem;
// begin
//   Assert(not Contains(ID));
// 
//   if GetCurrentNumberOfElements >= FMaxSize then
//     Evict(FMRU.Last);
// 
//   CacheItem := TCacheItem.Create(MakePair(ID, Item));
//   FMap[ID] := CacheItem;
//   Bump(CacheItem);
// end;

procedure TCache.RemoveLeastUsedElementFromCache;
begin
  if GetCurrentNumberOfElements >= FMaxSize then
    Evict(FMRU.Last);
end;

procedure TCache.AddItemToCache(ID: Integer; Item: TObject);
var
  CacheItem: TCacheItem;

begin
  CacheItem := TCacheItem.Create(MakePair(ID, Item));
  FMap[ID] := CacheItem;
  Bump(CacheItem);
end;

procedure TCache.Put(ID: Integer; Item: TObject);
begin
  Assert(not Contains(ID));

  RemoveLeastUsedElementFromCache;
  AddItemToCache(ID, Item); 
end;

'Bump' und 'Evict' sind für mich ungewöhnliche Begriffe. Ich würde zumindest 'Bump' anders benennen. Aber vermutlich ist das bei Dir/euch Standard. Dann müsste ich mich anpassen

Deckt sich ziemlich mit meiner Implementierung, nur das ich keine Generics habe und die MRU selbst implementieren muss.

PS: Es gibt keine Vorgabe, das eine MRU verwendet werden soll! ICH hätte das so gelöst. Wie ihr das macht, ist mir schnuppe (im Gegenteil: Sehr interessant)

[Namenloser]

Zitat von idefix2:

Ich spreche von meinem Algorithmus.
Du hast einen einfachen MRU (laut inzwischen modifizierter Vorgabe, im Eingangspost war etwas anderes verlangt) implementiert, da braucht man das natürlich nicht.

Achso, war wohl noch zu früh.

Aber wenn ich so drüber nachdenke, müsste sich der Ansatz mit der verketteten Liste auch für beliebige Sortierungen erweitern lassen. Denn das schöne ist ja, wenn wir das Element gecached haben, kennen wir automatisch die Position bzw. das Glied in der Liste. Dann müssen wir nach dem Updaten des Scores also nur schauen ob das „linke“ (vorherige) Element einen schlechteren Score hat und solange das geupdatete Element nach links verschieben, bis die Sortierung wieder stimmt (wie bei Insertion-Sort). Ist im Worst-Case zwar auch O(n), aber im Best-Case O(1). Es wird auf jeden Fall schneller sein als jedes mal alle Keys zu durchlaufen wie aktuell bei dir.

Zitat von Dejan Vu:

Gegenvorschlag?

Delphi-Quellcode:

TCache = Class;

TCacheHandle = class
protected
  FParent: TCache;
  { ... }
public
  property IsNull: Boolean;
  property ID: Integer;
  property Value: TObject;
  procedure Put(Value: TObject);
  procedure Remove;
end;

TCache = class
protected
{ ... }
public
  function GetHandle(ID: Integer): TCacheHandle;
  // Sonst keine öffentlichen Methoden
end;

Zitat von Dejan Vu:

Welche Gründe sprechen gegen private Felder? Properties sehe ich ein, aber Felder sollten so strict private sein, wie es nur geht.

Ja, da hast du recht, es wäre sauberer, die Felder private zu machen und über eine protected property Zugriff darauf zu gewähren. Bin aber meistens zu faul dazu und es bläht mir den Code zu sehr auf.

Ich habe bei private einfach die Erfahrung gemacht, dass man oft im Laufe der Zeit mehr und mehr Dinge doch noch protected macht, weil sich Nutzungsmöglichkeiten ergeben, die man am Anfang nicht vorhergesehen hat. Auch bei der VCL/RTL habe ich mich schon oft aufgeregt, dass Sachen sinnloserweise private waren und ich dann deshalb Code kopieren musste (Gruß an himitsu an dieser Stelle). Deswegen habe ich mir einfach angewöhnt: Im Zweifel für protected. Weil man sich da seltener was verbaut. Protected heißt bei mir daher aber auch immer ein bisschen „Use at your own risk“. Also bloß, weil man auf protected Felder zugreifen kann, heißt es nicht, dass man es unbedingt sollte. Da muss man eben Vernunft walten lassen. In Python gibt es übrigens gar kein private. Dort gibt es nur die Konvention, dass Variablen, die mit einem _ beginnen, tabu sind. Es wird sich eben darauf verlassen, dass der Programmierer sich daran hält, aber wer sich unbedingt in den Fuß schießen will, kann es tun. So ähnlich halte ich es auch.

Zitat von Dejan Vu:

Das 'MakePair' würde ich dem TKeyValuePair als Create spendieren. Gehört -finde ich- dorthin.

Habe ich auch schon oft so gemacht, als static class function. Aber damals gab es noch keine echten Konstruktoren von records, und das hat sich in neueren Delphi-Versionen ja glaube ich geändert. Ich wollte da lieber nichts verwenden, was ich nicht kenne.

Zitat von Dejan Vu:

Aber wieso gibst Du dort auch das 'Value' frei? Das ist doch das zu cachende Objekt? Damit hat doch der Cache nix am Hut. Oder hab ich mich verlesen?

Habe das so gemacht, weil TCache keinen OnRemove-Handler hat.

Zitat von Dejan Vu:

'Bump' und 'Evict' sind für mich ungewöhnliche Begriffe. Ich würde zumindest 'Bump' anders benennen.

Also Evict ist glaube ich schon ein Standardbegriff, Bump vielleicht eher nicht. Habe da irgendwie an Internetforen gedacht.

Aber wie heißt es so schön: „There are only two hard things in Computer Science: cache invalidation and naming things.“
Passt ja auch sonst zu diesem Thread.

[idefix2]

Zitat von Dejan Vu:

Zitat von idefix2:

Das Interface der Klasse habe ich bewusst etwas anders gestaltet als in der Vorgabe

Wieso hältst Du dich nicht an die Vorgabe? Wieso soll sich ein Cache um das Schreiben kümmern? Wieso soll er Statistiken pflegen?

Wenn die Cache-Klasse auch das Schreiben besorgt, muss die Anwendung zu speichernde Daten nur an einer Stelle "abgeben", sonst muss sie die Daten sowohl in den Cache schreiben als auch selbst auf das externe Medium speichern.
Mir erscheint eine Klasse, die transparent den Zugriff auf die Daten organisiert und dabei die Daten cached, wesentlich zweckmässiger als eine reine Cache-Klasse, in der man erst nachschauen muss, ob die Daten dort sind, und sich andernfalls die Daten von draussen zu besorgen. Und wenn man das macht, dann muss die Cache-Klasse die Statistik über Hits und Misses natürlich selbst führen, das Programm draussen bekommt davon nichts mit (und braucht davon auch nichts mitzubekommen)

Natürlich wird man sich für eine reine Cache-Klasse in einer Anwendung einen Wrapper Schreiben, der das erledigt, aber so erscheint es mir wesentlich eleganter. Das Schreiben könnte in dieser Klasse auch leicht in einen separaten Thread ausgelagert und gequeued werden, wobei Elemente im Cache geschützt bleiben und nicht hinausgeworfen werden dürfen, bis sie wirklich auf das externe Medium geschrieben sind. Wenn du das Schreiben ausserhalb des Caches erledigst, wird es mit einem separaten Thread wesentlich komplizierter, denn es könnte dir passieren, dass ein Element aus dem Cache gelöscht wird und dann wieder angefordert wird, während das Schreiben auf das externe Medium noch in der Warteschlange des anderen Threads steckt.

Zitat von Dejan Vu:

Im Ernst: Sollen wir für deine Sonderklasse extra eigene Test- und Prüfroutinen schreiben?


Schreib Deine doch bitte um, dann kann man die mit den MRU-Ansätzen vergleichen. Dein Algorithmus ist wirklich sehr interessant.

Das ist allerdings hier ein schlagendes Argument, an das ich nicht gedacht habe.
Ich werde schauen wann ich dazukomme, auch wenn ich den Ansatz prinzipiell für schlechter halte.

Zitat von Dejan Vu:

Ein Tipp bezüglich der function TCache.FindPlaceInCache: integer; : Du rennst mit einer For-Schleife durch die Liste? Das ist jetzt aber nicht so sonderlich performant, denn ein Cache verwaltet i.a. Millionen von Elementen.
Diese Routine wird bei jedem Cache-Aufruf einmal komplett durch alle Elemente laufen. Das kannst Du mit einer Priority-Queue (bzw. einem Baum) viel effizienter Lösen. Der wird bei jedem Zugriff sortiert bzw. mit wenigen Handgriffen angepasst, sodass dein 'worst element' immer automatisch 'oben' ist. Aber die Implementierung ist natürlich ungemein komplexer.

Schon klar. Ich habe ja geschrieben:

Zitat:

Für die aktuellen Cacheelemente sollte wohl zusätzlich noch eine nach dem "Hinauswurfkriterium" sortierte Liste verwaltet werden (oder sogar statt des TDictionary, aber dadurch würde das Auffinden der im Cache vorhandenen Elemente wieder langsamer), damit man nicht alle Elemente durchgehen muss, wenn ein Element aus dem Cache zu entfernen ist, um herauszufinden, welches weggehört. Eine einfache verkettete Liste, wie sie namenloser in seinem Algorithmus verwendet, bringt nicht viel, weil man dann die verkettete Liste trotzdem immer durchgehen muss, um das an Stelle des hinausgeworfenen Elements hinzukommende neue Element an der richtigen Stelle einzufügen, das ist nämlich auch nicht unbedingt am Ende der Liste.

Gestern Nacht war es mir schon zu spät, da hatte ich keine Lust mehr, das auch noch zu machen. So schlimm, wie du schreibst, ist es nicht, weil die Routine nicht bei jedem Cachezugriff aufgerufen wird, sondern nur bei Cache Misses, wenn der Cache voll ist. Und Millionen von Elementen sind es wohl auch nicht, es werden ja nur die aktuell im Cache befindlichen Elemente durchgegangen. Andererseits stimmt das, was ich geschrieben habe, auch nicht ganz, eine einfache verkette Liste würde trotzdem eine deutliche Verbesserung bringen, weil neue Elemente zwar nicht immer ganz ans Ende kommen, aber tendenziell doch eher im hinteren (hintersten) Teil der Liste landen werden, vor allem, wenn die MRU-Gewichtung grösser ist als die Häufigkeits-Gewichtung, was sie wahrscheinlich in den meisten Anwendungsfällen sein sollte.

Jetzt muss ich weg, vielleich komme ich übers WE noch dazu, da weiter zu machen.