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

Nein, nur leider baut die TList nicht auf eine (doppelt) verkettete Liste auf, sondern auf ein mitwachsendes Array.

Zitat von Der schöne Günther:

Nein, nur leider baut die TList nicht auf eine (doppelt) verkettete Liste auf, sondern auf ein mitwachsendes Array.

Was in 99% aller Fälle auch sinnvoll ist. In der Praxis sind Listen die intern auf Arrays basieren mindestens ähnlich schnell.
Der Cache heutiger Prozessoren ist eher dafür geeignet große zusammenhängende Speicherbereiche zu verarbeiten.
Passt das gesamte Array in den Cache (Objekte oder Pointer brauchen nur 8 Byte je Element), ist auch das Verschieben der Elemente kein Problem.
Selbst der oft angeführte Fall des häufigen Einfügen oder Entfernen von Objekten inmitten der Liste ist in der Regel bei verketteten Listen nicht spürbar schneller.
Das man erst einmal die richtige Stelle zum Einfügen finden muss, wird bei solchen Vergleichen meist vergessen.

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)