FastMM grotten langsam ?!

[negaH]

Zitat:

1. explizit per GetMem/FreeMem
2. implizit fuer Strings
3. indirekt fuer Objekte

3. würde einen festen Speicherbereich benötigen, da Objekte nicht mehr realloziert werden.

2. hat die höchste Wahrscheinlichkeit für Reallokationen und ein entsprechend großer Überhang bei der Allokation wäre hier am sinnvollsten um Fragmentierungen zu vermeiden

1. kann beides sein und wird eine Mixtur ergeben, die Fragmentierungen dürften hier am größten sein, dafür werden direkte Aufrufe von GetMem()/FreeMem() immer weniger in heutigen Libraries benutzt.

Es macht also durchaus Sinn darüber nachzudenken verschiedene Funktionen dafür zu coden.

Gruß Hagen

[Roland Wind]

Alles schön und gut. Aber wie stelle ich nun FastMM4 ein, dass er bei einer Multithreading Anwendung am effizientesten arbeitet ??. Weiters habe ich festgestellt, dass bei Verwendung von TVirtualTreeView beim Beenden angebliche Speicherlecks auftreten (MemProof hat da keine gefunden). Die .inc Datei des FastMM4 ist ja elends lange. Welche Schalter sollte man setzen ???

[alzaimar]

Wenn FastMM4 Speicherlecks findet, sind da auch Welche. Die .inc-Dateien sind zwar lang, aber lesen sollte man das schon. Das nennt sich 'user manual'. Dort findest Du dann auch die optimale Einstellung für multithreaded Anwendungen. Die habe ich nämlich nicht im Kopf und müsste auch erst lesen.

[himitsu]

SpeicherLeak's ... es ist schon so, daß FastMM nur Meckert, wenn beim Beenden noch irgendwelche Speicherbereiche reserviert sind, also nicht Freigegeben wurden, daß heißt, wenn da gemeckert wird, dann ist da auch ein Leak ... vielleicht sollte sollten die von MemProf mal bei sich suchen, wenn es da nichts findet.

PS: wozu ein User-Manual, die Kommentare in der .inc sind doch eigentlich soweit selbsterlärend.
Na ja, gerade deswegen ist bei meiner Version fast nichts mehr einzustellen

[Roland Wind]

Ist zwar richtig, das die Kommentare selbsterklärend sind. Trotzdem gibt es immer noich fragen. Ist es besser die Speicherleckerkennung aus/abzuschalten ?? Wie wirkt sich das auf die Laufzeit aus ?? Gibt es Schalterkombinationen, die die Effizienz des Speichermanagers erhöhen (in Bezug auf Multithreading) ?? Ich setze derzeit den FastMM bei einer Anwendung mit mehr als 1 Million Codezeilen ein. Da kommts auf jede 1/10 Sekunde an.

[Luckie]

Zitat von Roland Wind:

Ich setze derzeit den FastMM bei einer Anwendung mit mehr als 1 Million Codezeilen ein. Da kommts auf jede 1/10 Sekunde an.

Und diese eine Millionen Codezeilen werden immer alle gleichzeitig ausgeführt? Wenn dann kommt es bestimmt nur bei einem geringen bruchteil dieser eine Millionencodezeilen auf die Performance an, so dass die Größe des gesamt Projektes keine Rolle spielt.

[alzaimar]

Gut, meine Anwendung ist etwas kleiner, aber dafür werden die die Zeilen auch mehrfach ausgeführt (Stichwort: "Wiederverwendung von Zeilen" = Recycling = Gut für die Umwelt!)

Ich dachte mir zuerst, "nimmste FastMM4, dann geht die Luzie ab"... Nach umfangreichen Tests habe ich keinen signifikanten Unterschied festgestellt. Ich habe nur reihenweise Speicherlecks gefunden, denn da ist FastMM4 wirklich gnadenlos.

Zu deinen Fragen: Speicherleckerkennung kostet Zeit. Welche Schalter man bei Performanceoptimierung erst gar nicht anfässt, ist doch auch klar. Bleiben noch einige Optimierungsschalter, von denen gibt es vielleicht 3-5 Stück, macht 8-32 Kombinationen. Von denen widerum sind Einige nicht möglich, bleiben also doch nur eine Handvoll Kombinationen übrig.

Teste doch einfach mal, ich kann mir vorstellen, das es wirklich auf die Einzelanwendung ankommt. Und wenn Du Zig-Millionen Mal Speicher anforderst, kann es sein, das dein Programm von der Performanceseite her suboptimal gestaltet ist. Ich habe z.B. eine Anwendung, die benötigt Instanzen einer Klasse, die ca 8kb gross ist, und ständig. Anstatt die Klassen brav zu instantiieren, verwende ich eine eigene Garbagecollection und habe damit schon sehr viel rausgeholt.

Vor einiger Zeit gab es mal eine Diskussion (hier oder DF) um einen optimalen Speichermanager, denn es gibt ihn noch nicht.

[Bernhard Geyer]

Zitat von Roland Wind:

Ich setze derzeit den FastMM bei einer Anwendung mit mehr als 1 Million Codezeilen ein. Da kommts auf jede 1/10 Sekunde an.

Also bei mir hat FastMM erst einige Probleme gelößt wo ich mit dem normalen Delphi-Memory-Manager in OUT-OUF-Memory-Situation gestoßen bin (Problem der Fragmentierung beim alten MM). Und außerdem hatte ich große Geschwindigkeitszuwächse in ein paar kritischen Funktionen.

[himitsu]

Die Speicherleckerkennung verlangsammt den MM etwas und verbraucht auch noch etwas mehr Speicher, da ja irgendwie zusätzlich zum "normalen" Betrieb noch die Informationen für die Leckerkennung verarbeitet und gespeichert werden nüssen.

Was mit dem OutOfMemory hatte ich schonmal gesagt, ich bin mittler Weile soweit den MM von Delphi mit 'nem winzigen mehrdimensionalem Array (in meinem Fall war's ein String-Array) zu überlasten - virtueller Speicher war'n knapp 800 MB vorhanden und mit nichmal 50 MB tatsächlischem Speicherverbrauch meldete der Delphi-MM OutOfMemory und belegte selber fast den gesammten zur Verfügung stehenen virtuellen RAM.

Zitat von alzaimar:

Ich dachte mir zuerst, "nimmste FastMM4, dann geht die Luzie ab"...

Was das angeht, brauchst'e nur mal weiter vorne, oder in einigen der anderen Themen nachzulesen, da wurde das schon besprochen ... es gibt nicht immer einen Geschwindigkeistzuwachs ... in bestimmten Fällen kann FastMM sogar langsamer, als der Delphi-MM sein.