Moin,

also Sachen gibt's ... Ich habe hier eine Liste mit etwa 5-10 Mio. Einträgen. Ab und an muss ich diese Liste freigeben, um sie neu aufzubauen. Die Objekte sind etwas komplexer, so dass selbst das Freigeben dieser Liste eine messbare Zeit benötigt. Im ersten Ansatz bin ich treudoof von vorn nach hinten durch die Liste und habe die Elemente freigegeben. Das funktioniert selbstverständlich absolut zuverlässig.

Nun wollte ich mit zwei Threads daran: Jeder soll sich um eine Hälfte der Liste kümmern und von den Objekten den Destruktor aufrufen. Solange ich dabei nicht die Anzahl an Elementen in der Liste verändere, kann ich ja beliebig darauf herumkaspern - so mein Gedanke. Pustekuchen. Zwei Threads arbeiten länger an der Freigabe der Liste als meine simple Schleife. Mir ist klar, dass Threads einen gewissen Overhead haben, aber ob ich nun eine halbe Mio., 5 Mio. oder 15 Mio. Einträge habe - die Threads sind immer ein wenig langsamer. Da ich nur lesend auf die Liste zugreife und jeder der beiden Threads exklusiv seinen Bereich der Liste für sich hat, habe ich mir jede Form der Synchronisation gespart.


Was übersehe ich da? Eigentlich sollte ich mit Threads doch einen Vorteil erziehen können oder nicht?
Demo anbei, falls es wen interessiert.
FreeWilly.dpr

zusammenfalten · markieren

Delphi-Quellcode:

program FreeWilly;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils, System.Classes,
  System.Diagnostics,
  System.Threading,
  System.Generics.Collections;

type
  TMoep = class(TObject);

  TMoepManager = class(TObject)
  private
    FList : TList<TMoep>;
  public
    constructor Create;
    destructor Destroy; override;

    procedure Build;
    procedure Clear1;
    procedure Clear2;
  end;

{ TMoepManager }

procedure TMoepManager.Build;
var
  i : integer;
begin
  for i := 0 to 49999999 do // fuempfzig mio
  begin
    FList.Add( TMoep.Create );
  end;
end;

procedure TMoepManager.Clear1;
var
  i : integer;
begin
  for i := 0 to FList.Count-1 do
    FList[i].Free;
  FList.Clear;
end;

procedure TMoepManager.Clear2;
var
  LTasks : Tarray<ITask>;
  med : integer;
begin
  med := FList.Count DIV 2; // etwa die mitte

  SetLength( LTasks, 2 );

  LTasks[0] := TTask.Create(
    procedure
    var
      i : integer;
    begin
      for i := 0 to med do
        FList[i].Free;
    end
  );
  LTasks[1] := TTask.Create(
    procedure
    var
      i : integer;
    begin
      for i := med+1 to FList.Count-1 do
        FList[i].Free;
    end
  );

  LTasks[0].Start;
  LTasks[1].Start;

  TTask.WaitForAll( LTasks );

  FList.Clear;
end;

constructor TMoepManager.Create;
begin
  inherited;

  FList := TList<TMoep>.Create;
end;

destructor TMoepManager.Destroy;
begin
  FList.Free;

  inherited;
end;

var
  m : TMoepManager;
  s : TStopwatch;
begin
  s := TStopwatch.Create;

  m := TMoepManager.Create;

  m.Build;
  s.Start;
  m.Clear1;
  s.Stop;
  WriteLn( 'Clear1: ', s.ElapsedMilliseconds, ' ms' );

  s.Reset;

  m.Build;
  s.Start;
  m.Clear2;
  s.Stop;
  WriteLn( 'Clear2: ', s.ElapsedMilliseconds, ' ms' );

  m.Free;

  ReadLn;
end.

Mir dünkt, dass FastMM das Problem ist. Da war doch mal was, dass der nicht vollständig skaliert.
Komisch, dass man auf sowas erst kommt, wenn man das Problem niedergeschrieben hat.

Gibt es einen Grund warum du keine TObjectList nimmst? Wenn du die Liste neu aupfbaust, dann kannst du die Liste doch auch einem Thread zum Löschen geben und ein anderer Thread baut eine neue Liste auf.

Hast du übrigens schon mal die Zeit gemessen, die nur das FList.Clear benötigt? Das dürfte auch nicht unerheblich sein.

Mein echtes Projekt nutzt eine TObjectList, testweise habe ich auch dort mal eine TList versucht. Doch sobald ich sicherstelle, dass alle Destruktoren aufgerufen werden, zeigen die beiden Listenklassen keinen Unterschied in der Laufzeit.

Gleichzeitig freigeben und neu aufbauen habe ich noch nicht versucht, da der Neuaufbau mit n Threads erfolgt und schon alle CPU-Kerne auslastet. DORT habe ich noch Vorteile durch den Einsatz von Threads.

Üblicherweise ist Speicherverwaltung und mehrere Threads nicht wirklich toll. Im schlimmsten Fall serialisierst du das Freigeben durch einen Lock wieder vollständig (und hast dann noch den Overhead).

Wenn du die Liste eh wieder aufbaust: Kannst du die Objekte wiederverwenden? Die Performance-Leute für Sprachen mit GC machen das auch ganz "gerne".

Bei diesen Dimensionen und je nach Komplexität der Objekte könnte man auch darüber nachdenken, den Speicher für diese Objekte selbst zu verwalten.

EDIT: Wenn das einfach möglich ist, probiere auch mal die Objekte von dem Thread freigeben zu lassen, der sie erstellt hat. Wenn jeder Thread einen eigenen Heap hat (übliche Optimierung), dann solltest du so Konflikten aus dem Weg gehen.

Hast du mal versucht zwei komplett getrennte Listen zu benutzen und zu schauen wie lange deren parallele Freigabe dauert? Dort kannst du dann nämlich messen wie der Unterschied zwischen nur eine der Listen (ohne die zweite Liste) freigeben und parallel freigeben ist.
Wenn das dann pro Liste entsprechend länger dauert, bleibt nur noch der Speichermanager als Flaschenhals.

Mir war aber auch so als gäbe es da einen anderen Speichermanager, der genau bei vielen Threads sinnvoller ist, auch wenn er weniger als FastMM kann. Mir fällt nur gerade nicht ein wie der hieß...
Ach doch, kurz Google gefragt, scalemm:
https://code.google.com/p/scalemm/

Zitat von Daniel:

Mir dünkt, dass FastMM das Problem ist.

Das ist absolut richtig.

Ich habe gerade mal ScaleMM getestet. Der reserviert deutlich mehr RAM dabei, so dass es ein Out of Memory gibt und ist langsamer...
sapmm z.B. reserviert auch mehr, aber nicht so viel mehr, ist aber auch langsamer, insbesondere mit zwei Threads deutlich.

Ich bekomme so langsam das Gefühl, dass FastMM doch nicht so schlecht ist.

FastMM hat von den kleineren Blöcken extra mehrere, so daß bis zu 3 Threads gleichzeitig RAM "bestellen" können,

aber beim Freigeben oder Ändern kann, je Gruppe, natürlich immer nur Einer gleichzeitig, wenn die Speicher zufällig im selben Block liegen.

Zitat von himitsu:

aber beim Freigeben oder Ändern kann, je Gruppe, natürlich immer nur einer gleichzeitig, wenn die Speicher zufällig im selben Block liegen.

Das ist das Schöne an einer Lösung, wo man für eine konkrete Klasse noch einen Pool dazwischenschalten kann: Ich kann jedes Objekt in jeden Pool stecken, praktisch also auch ganz schnell in meinen Thread-lokalen.