Memory management mfc application

Hallo zusammen,

ich habe folgendes Problem bei dem ich nicht weiter komme. Vielleicht hat von euch jemand eine Idee.
Ich habe eine ActiveX Dll, bei der in der release version das Freigeben von Speicher extrem lange dauert (200 MB mehrere Minuten). Das Problem tritt bei folgender Speicheranordnung auf:
Ich habe mehrere std::vector variablen die auf Datenstrukturen zeigen. Das Problem tritt auf, wenn ich das Zeilenweise allokiere (also nacheinander an jeden Vektor ein Element anhänge, sind dann insgesamt mehrere tausend) und dann spaltenweise (einen vector nach dem anderen) wieder deallokiere.

Kurzes Beispiel:
Schleife über alle vektoren
Allokiere objekt und hänge es an vektor an
Ende Schleife

Schleife über alle vektoren
Schleife über alle vektor elemente
Gebe vektor element frei
Ende Schleife
Ende Schleife

Das hat wohl etwas mit der Speicherfragmentierung zu tun.
Dazu habe ich bereits ein Testprojekt aufgesetzt mit gleichem Code. Ergebnis: Debug version ist genauso langsam wie beim anderen Projekt die Debug und Release version, in der Release version des Testprojekts geht das jedoch super schnell.
Also wahr mein Verdacht, dass in der release Version des produktiven Projekts irgend eine Compiler/Linker Einstellung gesetzt ist, die nur in der Debug an sein sollte.
Ist aber leider nicht der Fall.

Hat von euch jemand eine Idee?

Danke schonmal im Voraus.

Martin Richter

Neuallokierung und clustering bei Vektoren kann man vermeiden wenn man vector::reserve an gescheiten Stellen verwendet.

Das die Debug-Version langsam ist liegt evtl. auch an den CRT-Flags, die bei jeder Allokation den Heap prüfen.
Das gibt es aber "grundsätzlich" nicht in Release Versionen.

Ein Fall für Profiling...

Es ist nicht der Vector selbst der beim deallocieren Probleme bereitet. Der wird ohne Zeitverzug freigegeben. Probleme hingegen bereiten die einzelnen Datenstrukturen die ich frei (also nicht zusammenhängend) allokiere.
Und um es nochmal klar zu machen geht es hier nicht um die allokierung von Speicher sondern nur um die Freigabe.

Jochen Kalmbach

TomTom1985 schrieb:

Und um es nochmal klar zu machen geht es hier nicht um die allokierung von Speicher sondern nur um die Freigabe.

Das eine hängt mit dem anderen zusammen...

WIE hast Du es gemnessen dass ein "free" so lange braucht?
Odert machst Du ein "delete"? Wenn ja, dann schau mal nach, was im Destruktor so alles gemacht wird..

Habe zufällig etwas herausgefunden. Das liegt wohl am debug heap von visual studio. Wenn man eine Applikation von Visual studio heraus startet, dann wird ein anderer heap verwendet der viel langsamer ist. Jetzt frägt sich nur, warum bei mir in der release Version wenn ich das ohne visual studio starte der debug heap verwendet wird???
_NO_DEBUG_HEAP habe ich versucht während der Laufzeit abzufragen, wurde aber nicht gefunden. Also ist das wohl nicht gesetzt.
Ist schon irgendwie komisch...

Jochen Kalmbach

Mit dem "starten" hat das nix zu tun.... nur mit dem linken: Gegen Welche Runtime linkst Du denn?

Und ja, in der Debug-version sind wesentlich mehr Checks drin. Auch die STL hat mehr checks...

Siehe dazu auch:

_HAS_ITERATOR_DEBUGGING
http://msdn.microsoft.com/en-us/library/aa985939(v=vs.100).aspx

Checked iterators
http://msdn.microsoft.com/en-us/library/aa985965(v=vs.100).aspx

Martin Richter

Es hängt auch damit zusammen, welche CRT Flags gesetzt werden:

http://blog.m-ri.de/index.php/2008/11/04/vs-tipps-tricks-heap-bugs-finden-teil-3/
http://blog.m-ri.de/index.php/2008/10/31/vs-tipps-tricks-heap-bugs-finden-teil-2/
http://blog.m-ri.de/index.php/2008/10/27/vs-tipps-tricks-heap-bugs-finden-teil-1/

Alle diese Funktionen haben natürlich massiven Einfluß auf die Performance!

Ich habe mir mit "HeapQueryInformation" den heap typ abgefragt. Der steht bei der Problem Application immer auf 0. Auch wenn ich die release version nicht über visual studio starte. Das setzen von _NO_DEBUG_HEAP auf 1 bringt auch nichts. In meinem Test-Projekt ist der heap modus immer "2" wenn ich die Applikation ohne Visual Studio starte.

Habe das Problem selbst gelöst.
Irgendwo im System (aber sicher nicht die registry) ist hinterlegt, dass diese eine Applikation immer mit debug heap ausgeführt wird. Habe das mal getestet, indem ich die Applikation umbenannt habe. Lief dann mit LFH. Wenn ich meine Test Applikation in den Ordner kopiere und gleich benenne wie die Problem Applikation dann läuft auch diese mit debug heap.
Im Verdacht steht das tool AQTime. Ich glaube dieses ist dafür verantwortlich.

Martin Richter

Hast Du den Application Verifier in Verwendung?

Ich habe den eigneltich nie wissentlich verwendet. Allerdings stehen vom letzten Jahr ein paar loggs drin. Zumindest ist die Anwendung aktuell nicht im AppViewer eingetragen.