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

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.

Habe ja nicht gesagt dass ich das schlecht finde- Das "leider" bezog sich auf Vermutung "Wenn es eine verkettete Liste ist, dann..."

Auf jeden Fall wieder was gelernt.

Zum Thema Objekte wiederverwenden:

Dafür könnten diese Methoden der Klasse TMoep überschieben werden:

markieren

Delphi-Quellcode:

class function NewInstance: TObject; override;
procedure FreeInstance; override;

Benötigt wird eine globale Liste für verfügbare TMoep-Objekte.
FreeInstance speichert "freigegebenen" Objekte in dieser.
NewInstance kann sich aus der Liste bedienen, so lange noch "freigegebene" Objekte vorhanden sind.

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)

Zitat von himitsu:

Auch mehr Threads versucht? (4 oder 8 ... k.A. was du für eine CPU hast)

Der VM habe ich vier Kerne zugewiesen. Beim Aufbau der Liste passen Theorie und Praxis auch wunnebaaa z'ammen und bei vier Threads habe ich die höchste Performance.

@Blup: Spannende Idee, aber ich sehe mich schon mit Löchern im Strumpf, weil ich mir damit mit hoher Wahrscheinlichkeit selbst in den Fuß schieße. Ich werde das am Wochenende aus Interesse mal ausprobieren, wenngleich ich noch Zweifel habe, ob das der Wartbarkeit des Gesamtprojekts entgegenkommt.