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/

Im echten Projekt habe ich eine Baum-Struktur. Im konkreten Testfall mit rund 1.800 Elementen auf unterster Ebene. Diese Elemente haben ihrerseits Unter-Elemente in jeweils eigenen Listen, so dass ich in Summe auf die eingangs beschriebene Größenordnung komme.
Die beiden Threads hätten sich die 1.800 Root-Elemente aufteilen sollen. Das zeitliche Verhalten lässt sich mit einer langen Liste identisch nachstellen, so dass ich den Speichermanager als Flaschenhals vermute. FastMM macht ja im Allgemeinen einen guten Job, so dass ich vorläufig an ihm festhalten möchte.

Das Thema ist nicht kritisch - ich halte fest, dass es nicht "mal eben so" möglich ist, hier spürbare Vorteile zu erzielen. Ein großartiges Umbauen der Datenstruktur kommt vorläufig nicht in Frage - zumindest nicht mit der alleinigen Motivation, lediglich das Freigeben zu beschleunigen. Manchmal ist die serielle Abarbeitung ja auch ganz charmant. Nun lege ich wenigstens die in einen Thread, so dass die App nicht blockiert.

Was für Zeiten hast Du denn wo gemessen?

Gemessen habe ich wie oben in meinem Beispiel: Den Gesamtaufwand für Clear1 bzw. Clear2. Also inklusive Erzeugen der Thread-Objekte etc. Das war für mich am naheliegensten, da ich wissen will, wie lange es dauert, mich der Daten wieder zu entledigen.

Die konkreten Werte sind natürlich hardware- und projektabhängig. In meinem Testprojekt messe ich konstant um 300ms für das Zerstören der Liste. Das ist ein Wert, der mir - gerade nach den obigen Überlegungen - zu wenig Leidensdruck verschafft, um hier noch mehr Zeit zu investieren. Es war für mich einfach eine neue Erkenntnis, dass da im Kontext des Speichermanagements offenbar Grenzen existieren.

10-15 ms kannst Du sparen, wenn Du vorberechnete Werte für die Schleifen verwendest:

markieren

Delphi-Quellcode:

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

Die Werte der For-Schleife sind immmer vorberchnet, da Delphi den Endwert zwischenspeichert.

15ms ... wenn du das mit GetTickCount oder Dregleichen gemessen hast, dann ist das eher ein Messfehler.


TTask?
Warum nimmst du nicht die neue "coole" threaded For-Schleife?


Bezüglich des Threads:
Wenn die FList und deren Objekte nirgendwo dran hängen, also wie z.B. Owner/Parent-Bezieungen zu deiner Basisklasse (TMoepManager). (auch bei TComponent oder Dregleichen aufpassen, daß es nirgendwo weitere globale Listen/Registrierungspunkte gibt)

• eventuelle Beziehungen zur Basisklasse auflösen
• FList mit einer Temp-Variable (nil) tauschen
  oder alternativ nur den Inhalt von FList in eine andere Liste übertragen
• nun die ganze Liste an den Thread/Task übergeben (der gibt das frei)
• fertig und sich nicht weiter drum kümmern

PS: Im Gegenzug, kannst du dann auch das erstellen auch in Threads/Tasks machen, oder die neue Liste schonmal vorher erstellen und dann ebenso austauschen.

Moin,

ich bin mir nicht so ganz sicher, wie Delphi die Listen verwaltet. Aber wenn es eine normale verkettete Liste ist könnte es effizienter sein von hinten anzufangen...(auch der Vergleich auf 0 als Endkriterium für eine Schleife ist normalerweise schneller als der Vergleich auf einen festen Wert)

Gruß
Dirk

P.S.: hoffe habe nicht allzu großen Schwachsinn erzählt...

Zitat von himitsu:

Die Werte der For-Schleife sind immmer vorberechnet, da Delphi den Endwert zwischenspeichert.

Da hast Du natürlich Recht. In dem Fall ist vielleicht das Aligment Schuld, bei der minimal langsameren Variante ist der Zugriff auf den Schleifenzähler nicht optimal [ebp-$0c] im Gegensatz zu [ebp-$10].

Zitat von himitsu:

TTask?
Warum nimmst du nicht die neue "coole" threaded For-Schleife?

Alles schon probiert. Klassischer TThread, TTask oder TParallel - liefert alles das gleiche Ergebnis.

Zitat von himitsu:

...fertig und sich nicht weiter drum kümmern

Das wäre noch eine Variante, wobei ich auch ein Auge auf den Speicherverbrauch haben muss, denn der Krempel ist empfindlich groß.

Vielleicht fällt dir der Speichermanager auf die Füsse?

Kleine Speicherblöcke legt FastMM doch in mehreren größeren Blöcken an, die durch CriticalSections geschützt sind.
Zwei Threads, die auf den selben Verwaltungsblock zugreifen, sperren sich dann natürlich.


Insgesamt hätte ich dennoch eine Beschleunigung erwartet, außer der Overhead durch die Threads/Tasks hebt das wieder auf.
Auch mehr Threads versucht? (4 oder 8 ... k.A. was du für eine CPU hast)