Zitat:
ob Du konkrete Erfahrungswerte für den Einsatz eines Nodemanagers für die Objekterstellung anbieten kannst:
Ja, aber aus ganz anderen Gründen. 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. In diesem speziellen Fall wurden ALLE Operationen auf diesen "forged Interfaces" ca. 10% beschleunigt. Allerdings in der Gesamtperformance spielte der Speichermanager von vornherein eine unwichtigere Rolle. D.h. diese 10% müssen viel höher bewertet werden als die Zahl 10 dies suggeriert ! Nur ca. 0.01% von allen Operationen sind Aufrufe zum Speichermanagement. Somit sind die 10% viel mehr als von mir tatsächlich erwartet.
Zitat:
Für welche Exemplargrößes lohnt sich der Einsatz?
Am einfachsten und effizientesten sind Records mit fester Größe. D.h. der MM Ersatz verwaltet nur Objecte/Records die eine gleichbleibende Speichergröße besitzen.
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.
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. Um so häufiger Alloziert/Dealloziert wird um so größer ist der Zeitgewinn. 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. D.h. nur 0.005 Prozent der Speicheranforderungen. Da der Pool selber Threadbezogen arbeitet, d.h. jeder Thread hat seinen eigenen Pool, entfällt das Locking per
RTL-CS. Alleine dies würde im Borland MM 2 Mio mal erfolgen.
Zitat:
Was gewinnt man bei eine Initialisierung direkt in NewInstance?
Arbeitet man mit Klassen so bleibt einem garnichts anderes übrig als .NewInstance zu überschreiben. Nur innerhalb von .NewInstance kann für eine spezielle Klasse deren Allokation geändert werden. Im gleichem Maße muß man demzufolge auf .FreeInstance überschreiben.
Zitat:
Wie groß sollten die Chunks gewählt sein?
Abhänig vom Datenaufkommen. Am besten ist es wenn der Pool nicht linear wächst. Statt also immer 1024 Objecte per Chunk zu allozieren, könnte man auch den Pool um 16,32,64,128,256... usw. Objecte vergrößeren. Damit würde der Pool sich nichtlinear anpassen. Man sollte den Pool konfigurierbar halten. D.h. die Zuwachsraten und nach welcher Methode sollten einstellbar sein.
Zitat:
Gibt es elegante Lösung für Polymorhpie, also unterschiedliche Exemplargrößen?
Jo, den integrierten Speichermanager
Meiner Meinung nach lohnen eigene Pools nur wenn man wirklich das letzte Quentchen rausholen muß UND alle anderen Optimierungsoptionen schon ausgschöpft hat. In meiner Library war dies ein bischen anders. Meine Anforderungen entstanden hauptsächlich aus dem Ziel per "Interfaces" das autm. Reference Counting + Garbarge Collection + Copy on Write Demand + Autoallokation umzusetzen. Da von vornherein feststand das die Recordgrößen fixiert sind war es sinnvoll all diese Features über einen Speicher-Pool zu erledigen, der zudem noch threadsicher sein sollte.
Gruß Hagen