FastMM grotten langsam ?!

[himitsu]

Zu 1:
Denkbar ist vieles, sogar sowas, nur wird es halt schwierig festzulegen wann es sich um ein COM/OLE-Objekt handelt.

Zu 2 und 3:
Ich habe ja mit Absich nicht etwas derartiges eingebaut, obwohl ich es Anfangs vor hatte und FastMM besitzt auch nichts vergleichbares.
Denn wie Hagen schon sagte, es ist unmöglich für den MM festzustellen ob ein Speicherblock noch benötigt wird, selbst wenn der Thread, welcher diesen hat allocieren lassen längst beendet ist, denn es kann ja durchaus sein, daß der Speicherblock an einen anderen Thread übergeben wurde, was der MM ja nicht wissen kann.

[mschaefer]

Moin, Himitsu

bei Deinem Speichermanager mußte ich leider feststellen, dass er nich unter D6 zu compilieren ist, sodass ich jetzt auch keine Vergleich liefern kann. Aber letzlich ist doch das Resultat, dass diese Speichermanager nur da interessant sind, wo im wesentlichen mit einer Anwendung auf dem Rechner gearbeitet wird. Oder ist das jetzt überinterpretiert?

Grüße //Martin

[himitsu]

Tut mir Leid .. das ist ja nur 'ne Auskopplung aus meinem UCC und dort hatte ich noch keine Zeit es abwärtskompatibel zu machen ... aber bis auf D4 runter sollt es mal irgendwann laufen ._.

Aber kannst du mir mal sagen was da nicht laufen will?
(hab derzeit mein D4 nicht installiert)

[negaH]

Zitat:

Denn wie Hagen schon sagte, es ist unmöglich für den MM festzustellen ob ein Speicherblock noch benötigt wird, selbst wenn der Thread, welcher diesen hat allocieren lassen längst beendet ist, denn es kann ja durchaus sein, daß der Speicherblock an einen anderen Thread übergeben wurde, was der MM ja nicht wissen kann.

Dies trifft das Problem leider nicht exakt.

RecyclerMM alloziert quasi für jeden Thread einen eigenen unabhängigen Speichermanager. Nun stellen wir uns mal vor dieser Thread übergibt tatsächlich einen für ihn allozierten Speicherbereich einem anderen Thread.
Was soll passieren wenn der allozierende Thread nun terminiert wird ? Reagiert RecyclerMM darauf und zerstört den threadeigenen Speichermanager so zerstört er für den anderen Thread diesen übergebenen Speicherblock. Reagiert RecyclerMM aber nicht auf die Termination des Threads so bleiben Speicherleichen übrig.

Dieses Verhalten kann mit einem threadübergreifenden MM, wie dem BorlandMM oder FastMM4 nicht auftreten.

Man kann aber durch eine ausführliche Dokumentation und eventuell vorhanden spezielle Kopierfunktionen dieses Problem umgehen.

Wichtiger ist einfach die Frage ob es einen allgemeingültigen und immer funktionierenden Weg gibt das RecyclerMM auf die Terminierung eines beliebigen Threads reagieren kann. Und diese Frage muß man auf API Ebene ganz klar mit "nicht möglich" beantworten. Der einzisgte Ausweg wäre ein virtueller Treiber der sich in das Kernel einklinkt und auf die Termierung eines beliebigen Threads reagiert.

Gruß Hagen

[negaH]

Zitat:

1.) Wäre es überhaupt denkbar einen Speichermanager so anzupassen, dass er bei Com und OLE Objekten keinen größeren Speicherbereich anfordert, also nur auf normale Objekte mit seiner Optimierung reagiert.

Um die Größe des Overheads geht es hier garnicht. Es geht noch nicht mal um die Allozierung sondern um die Deallozierungen, diese sind das Problem.

Man könnte mit Sicherheit einen MM programmieren der mehrere GetMem() Funktionen besäße. Je nach gewünschtem Verhalten würden diese GetMem() Versionen unterschiedliche Speuicheranforderungen durchführen. Zb. eben ein GetMem() für die LongStrings die mit hoher Wahrscheinlichkeit ReallocMem() aufrufen. Und ein anderes GetMem() für Speicherbereiche die immer fixierte Länge besäßen.

Zitat:

2.) Endet das letztlich in einer Art zeitgesteuerten Garbage-Collection. Dein Speichermanager müßte ja in den Idle-Zeiten genauer Untersuchen welche Speicherlücken er noch freigeben kann.

Nee. Alle MMs die ich kenne entscheiden sofort wie sie einen freizugebenden Speicherbereich wieder defragmentiert einzuordnen haben. Sie erkennen also schon bei der Deallokation ob die Speicherbereiche nach und vor dem aktuellen ebenfalls schon freigegeben wurden. Ist dies der Fall werden diese Fragmente sofort zu einem größeren Block zusammengeführt.

Die Idle Methode bezog sich darauf die Threadeigenen MMs innerhalb vom recyclerMM wieder freizugeben. Dabei wird periodisch überprüft ob zu einem Threadeigenem MM der Thread noch gültig ist. Nur gibt es eben auf API Ebene keinen Weg zu erkennen ob ein Thread Handle oder ThreadID noch gültig ist. Dies ist im Grunde exakt das gleiche Problem mit Objektreferenzen. Also Zeiger auf Objekte bei denen aber das Objekt schon längst wieder freigegeben wurde. Der Objektzeiger zeigt also in einen Speicherbereich in dem schon längst nicht mehr das originale Objekt gespeichert ist sondern entweder garkeines oder noch viel schlimmer ein neues der gleichen Klasse, aber eben NICHT mehr das originale ! Da Windows ebenfalls die Handles in der internen Handletabelle zum Prozess wiederverwendetet und unter Win95 zb. die ThreadID direkt korrespondiert zum Speicherbereich des Threadhandles (ThreadID ist quasi ein umgerechneter Wert des Speicherbereiches auf den das Handle zeigt), entsteht somit exakt das gleiche Problem wie bei den Objekten. Man kann definitiv nicht erkennen ob ein Thread Handle/ID noch der original gemeinte Thread ist.

Zitat:

3.) Ist das nicht eher die Aufgabe eines Programm unabhängigen Dienstes?

Hm, weis ich nicht. Ob man das als Dienst, DLL oder ins Kernel einbaut ist erstmal egal, Code bleibt Code. Wohin man das einbaut hat nur Relevanz bei der finalen Entscheidung in welcher Form man das Produkt vermarkten möchte. Der Ort wo der Code steht entscheidet also erstmal nicht was der Code ansich für Aufgaben erledigen soll.
Man kann zb. einen TCP/IP Server als DLL, Dienst oder eigene Anwendung programmieren, dadurch ändert sich aber nichts am Verhalten des Servers ansich.

Zitat:

2.) Endet das letztlich in einer Art zeitgesteuerten Garbage-Collection. Dein Speichermanager müßte ja in den Idle-Zeiten genauer Untersuchen welche Speicherlücken er noch freigeben kann.

Ich vermute mal das du mit dieser Frage eher auf den "strategisch intelligenten" MM anspieltest. Wie ich oben sagte wäre das das einzigste was mich überhaupt dazu bewegen könnte nochmals einen MM zu coden (neben einem finanziellen Profit wohlgemerkt )

Konzeptionell würde ich ein solches System aber anders angehen. Zb. einen MM der einen "Lern-modus" enthält. Wie oben angedeutet gäbe es verschiedene GetMem() Funktionen. Eine für definitiv sich reallokierende Funktionen und einen für fixed Size Allokationen.

Man bindet einen solchen MM ganz normal in seine Anwendung ein, per Compilerswisches im "Lern"-Modus. Der MM protokolliert nun jede Speicherallokation und auch die Reallokationen schon bestehender Speicherbereiche. Ausgehend davon ermittelt er also mit welcher GetMem() Funktion,sprich welchen Typus von Speicher die Anwendung zu jedem zeitpunkt benötigt. Daraus ermittelt er zb. das Funktion XYZ immer nur Speicher alloziert mit fester Größe a 32 Bytes. Diese Information führt dazu das im Patch-Modus der MM eine spezielle GetMem() Funktion an die originale Stelle des Funktionsaufrufes hinein "patcht". Die Funktion XYZ ruft ab jetzt immer eine GetMem() Funktion auf die nur Blöcke von 32 Bytes in einem speziellen Speicherbereich alloziert.

Oder Funktion ABC führt eine LongString Berechnung durch. Dabei wird er String additiv vergrößert, von zb. 4 Zeichen auf durchscnittlich 1024 Zeichen +-128 Zeichen. Diese statistischen Infos werden im MM im Lernmodus ermittelt und führen nun im gepatchten Modus dazu das der erste Aufruf von GetMem() in Funktion ABC sofort einen String mit Länge 1024 alloziert.

So bei diesem MM gäbe es noch einen Lernmodus und eine finale gepatchte Anwendung. Schafft man es dies statistischen Informionen aber kompakt und permanent aktuell zu halten so könnte man auch auf diese 2 Phase verzichten und der MM würde quasi permanent lernen und entscheiden.

Gruß Hagen

[negaH]

Im Lernmodus könnte man die zusätzlichen statitischen Infos selber im Speicherblock speichern, sprich Addresse des GetMem() aufrufes in der übergeordneten Funktion, erstmalige Speichergöße, Anzahl der Reallokationen, durschnittliche Reallokations-Größe in Bytes und finale maximal Speichergröße. Diese Daten werden dann extern gespeichert für die spätere Auswertung. Man lässt also die Anwednung erstmal unteer verschiedenen Umweltbedinugen laufen. Später in der Auswertung kann man nun anhand dieser Daten erstmal überprüfen wo und wann Speicherlecks auftreten. Dann kann man noch unterscheiden zwischen Speicherallokationen mit immer fester Größe und somit all diese Aufrufe auf eine spezielle GetMem() Funktion umleiten. Oder man erkennt das ein Speicherbereich oft vergrößert wird und ermittelt die durschnittlich beste Speichergröße. Wiederum diregiert man die GetMem() Aufrufe zu einer speziellen Version um die nun schon beim ersten Aufruf einen Speicherbereich auf die durchschnittliche Größe alloziert.

Aus all diesen Infos entsteht quasi ein Patch-Protokoll das die finale Version des Programmes mit dem nicht-lernfähigen MM entsprechend abändert.

Gruß Hagen

[alzaimar]

Nur so mal, als kleine Anekdote: Der SQL-Server von Microsoft verzichtet aus Performancegründen komplett auf einen Speichermanager im herkömmlichen Sinn. Alle internen Datenstrukturen sind statisch angelegt. Der "Speichermanager" verwaltet die Pages (also die Seiten in denen die Daten stehen) als verkettete Liste: Seiten, die am Ende der Liste gelandet sind, werden ggf. recycled oder an Windows zurück gegeben (selten).

Im Endeffekt bedeutet das, das das 'komfortable' Arbeiten mit einer dynamischen Speicherverwaltung eben Zeit kostet. Wenn man wirklich schnelle Programme benötigt, muss man sich eben davon verabschieden.

Wie so oft gilt auch hier: Das Design entscheidet über Performance.

Ich halte auch Nichts von langwierigen Analysen der konkreten Speicheranforderungen einer Applikation. Denn hier wird man höchstens marginal etwas verbessern können: Eine Anwendung, die schnell laufen muss, aber Millionen von Speicherblöcken alloziiert und freigibt, hat einen Designfehler und 'verdient' es nicht, das man an ihr rumdoktort, denn es ist anzunehmen, das die Applikation auch sonst schlecht geschrieben ist.

[negaH]

Zitat:

Ich halte auch Nichts von langwierigen Analysen der konkreten Speicheranforderungen einer Applikation. Denn hier wird man höchstens marginal etwas verbessern können: Eine Anwendung, die schnell laufen muss, aber Millionen von Speicherblöcken alloziiert und freigibt, hat einen Designfehler und 'verdient' es nicht, das man an ihr rumdoktort, denn es ist anzunehmen, das die Applikation auch sonst schlecht geschrieben ist.

Logische und eigentlich simple Deduktion, dem kann ich mich nur anschließen.
Denoch meine ich das ein komplett neuer MM der die Aussicht auf wesentlich bessere Performance als die bisherigen haben soll, nur mit einem komplett neuem Konzept Erfolg haben kann. Und gerade ein "strategisch intelligenter" MM entlastet ja den Programmierer von der Verantwortung und dem Aufwand sich über bessere Datenstrukturen und Optimierungen in den eigenen Algorithmen Gedanken machen zu müssen. Und diese Sichtweise ist nicht zwangsläufig eine schlechte Sichtweise.

Eines weis ich aber mit Gewissheit: die jetzigen MMs wie FastMM4 haben die bisherigen Konzepte im Grunde bis an ihre Grenze ausgenutzt. Um sie nun noch performanter zu machen müssen sie weitreichendere Information sammeln und dann entsprechend auch nutzen. Ich meine also das man sehr wohl noch nicht die Performancegrenze ansich erreicht hat, sondern nur das die bisherigen Algorithmen ausgereizt sind.

Gruß Hagen

[himitsu]

Das mit dem Informationen sammeln hab ich ja im Moment etwas anders gelöst ... bei meinen String-Funktionen kann man ja (wenn nötig) selber entsprechende Informationen mitgeben. Es ist also möglich selber zu beeinflussen, wie das Speichermanagement arbeiten soll und es so etwas an seine Bedürfnisse anzupassen.

[Robert Marquardt]

Es gibt durchaus eine begrenzte Moeglichkeit mehrere spezifische Memorymanager parallel zu fahren.
Es gibt naemlich drei verschiedene Typen von Alloziierungen/Dealloziierungen in die man sich einklinken kann.
1. explizit per GetMem/FreeMem
2. implizit fuer Strings
3. indirekt fuer Objekte

Damit koennte man drei verschiedene Pools mit spezifisch optimierten Strategien implementieren, denn
die alloziierten Elemente koennen nicht von einem Pool in den anderen geraten. Zumindest nicht durch
Code der nicht komplett falsch ist. Niemand wuerde auf die Idee kommen das ein FreeMem auf ein Objekt
eine ungefaehrliche Operation ist.