Zitat von
Hagen:
Zitat:
ob Du konkrete Erfahrungswerte für den Einsatz eines Nodemanagers für die Objekterstellung anbieten kannst:
Ja [...]. Ich benötigte einen Pool von gleichgroßen Records die aber per Reference Counting, sprich Interfaces, arbeiteten. Dadurch wurde mit Hilfe der integrierten Fähigkeiten des Delphi Compilers, ein automatisches Garbarge Collection und "Copy on Write Demand" realisiert. [...] Somit sind die 10% viel mehr als von mir tatsächlich erwartet.
Das kommt dem, was ich zZt noch mit dem Borland Memory Manager (BMM) realisiere, ziemlich nahe: Lediglich mit dem Unterschied, dass meine "forgotten Interfaces" als gecachte Werte erst bei Bedarf als "freie Nodes" gekennzeichnet werden, weil sie in den meisten Fällen ohnehin kurze Zeit später erneut "erbaut" werden würden...
Zitat von
Hagen:
Zitat:
Für welche Exemplargrößes lohnt sich der Einsatz?
Am einfachsten und effizientesten sind Records mit fester Größe. [...] Für variable Speichergrößen, würde ich beim Borland MM bleiben, denn dieser MM ist eigentlich schon enorm optimiert und einer der schnellsten überhaupt.
Diese Antwort deckt sich mit Deiner Äußerung zur Polymorphie. Danke.
Zitat von
Hagen:
Zitat:
Wie groß ist der tatsächliche Zeitgewinn bei welchen Mengen von Exemplaren?
Dioes hängt hauptsächlich von der Größe und der Häüfigkeit der Records ab. [...] In meiner Library hatte ich ca. 2 Mio solcher De-/Alloziereungen pro Berechnung. Durch den Pool wurden die tatsächlichen Aufrufe zum Borland MM auf ca. 10.000 reduziert. [...] Da der Pool selber Threadbezogen arbeitet, [...] entfällt das Locking per
RTL-CS.
Gerade das Veremeiden des Lockings klingt interessant...
Zitat von
Hagen:
Zitat:
Was gewinnt man bei eine Initialisierung direkt in NewInstance?
Arbeitet man mit Klassen so bleibt einem garnichts anderes übrig als .NewInstance zu überschreiben.
Das ist mir schon klar, Hagen, ich meinte aber eher Vorbelegung von Exemplarvariablen, Referenzzählern direkt in
NewInstance anstatt diese Belegung in
InitInstance bzw. im Konstruktor vorzunehmen. Hier könnten neue Nodes mithilfe eines "Node-Templates" mit
rep movsd relativ performant erzeugt werden...?
Zitat von
Hagen:
Ach eines noch. Der Performancegewinn wurde aber wahrscheinlich aus einem ganz anderen Grund erreicht. [...] Da mein Pool als FIFO arbeitet rotieren sozusagen die allozierten Speicher im Pool. Dadurch passiert es das der Pool succesive Speicherbereich auch meistens succesive im Cache halten kann. [...] Eine Speicherkopieroperation zwischen zwei solcher unabhäniger Cachelines ist dann sehr viel scheller und verhindert Cachmisses der CPU. Eineinzigster solcher Cachemiss kann ca. 200 Taktzyklen beanspruchen.
Interessanter Aspekt.
Danke Hagen, für Deine ausführliche Darstellung!