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/

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?

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.