Suche tool -> Speicherverbrauch
-
ich glaube du kommst nicht umhin, jede Variable einzeln zu zählen
Zumindest bei Varaiblen auf dem heap kannst du durch einen Allokator die deklarierten Bytes zählen.
-
Das Problem ist, dass wir ziemlich komplexe Software geschrieben haben und das bei jedem Funktionsaufruf ein Speicherzuwachs von ca. 13MB ist (festgestellt im TaskManager). Jetzt will ich wissen was mit dem Speicher ist
-
Wen ihr die Software geschrieben habt, warum jagt ihr sie nicht mal durch den Debugger? Damit lassen sich auch schon so einige Speicher-Probleme finden.
-
memory leaks gibt es ja keine, da der allokiete Speicher ordnungsgemäß freigegeben wurde. Das ist ja das komische
-
Hi!
Es war nicht die rede von Speicherlecks sondern von Speicherproblemen allgemein. Prüfe doch einfach mal wo überall Speicher reserviert wird und wann dieser freigegeben wird. Wenn er immer nur am Ende freigegeben wird, dann solltest du sehen ob der Speicher nicht früher freigegeben werden kann.
Dafür braucht man kein Programm. Mir wurde mal der Tip gegeben das ich unter Linux mein Programm mit ddd tracen soll, hatte da nämlich auch ein paar Speicherprobleme (wobei sich das nach genauem hinsehen und komplett neugeschriebener Logik erübrigt hatte).
Code-Hacker
-
Lad dir mal "Compuware DevPartner Studio" mit eMule runter. Damit geht das bestimmt.
-
*hust, hust*
-
Der Hinweis auf die Software hätte genügt.
-
interpreter schrieb:
Eine Funktion als Ganzes verbraucht sowieso keinen Speicher.
Doch, zumindest Stack. Kann natürlich aber nicht das Problem von Horst2 sein.
Horst2 schrieb:
memory leaks gibt es ja keine, da der allokiete Speicher ordnungsgemäß freigegeben wurde
Woher willst du denn das wissen? Mit dem Task Manager kannst du höchstens bestimmen, dass dein Programm resource leaks verursacht, mehr aber nicht. Da die meisten BS beim Beenden des Programms so höflich sind fehlende Speicherfreigaben auszugleichen, muss man memory leaks über andere Wege erkennen. Eine Möglichkeit wäre, sich eigene Allokatoren/Deallokatoren zu schreiben. C++ bietet dafür zB überladene new/delete Operatoren an. Imo eine elegantere Möglichkeit sind smart pointer. Die sorgen dafür, dass im Destruktor der Speicher automatisch freigegeben wird, ohne dass man sich darum kümmern mus. Und für dynamische Arrays ist es eh besser, wenn du auf Klassen zurückgreifst, die sich selbst um das Speicher-Management kümmern, wie std::vector.
Das dein Programm von solchen Massnahmen profitiert, erfordert uU, dass die Software mehr oder weniger komplett überarbeitet werden muss. Schnellere Aussagen kann man durch das Ermitteln des freien Speichers zu Beginn und Ende des Programms machen (musst du aber auf OS spezifische Funktionen zurückgreifen, da Standard C++ dafür nix anbietet). Natürlich ist das nicht genau, da ja auch noch andere Prozesse laufen. Aber man kann zumindest sehen, ob zig MB Speicher im Nirvana gelandet sind.
-
Dem new operator kannst du ja noch zusätzlich __LINE__, __FILE__ und __FUNC__ übergeben (__FUNC__ ist zwar nicht standard aber ein Debug Trick muss ja nicht portabel sein). Und das ganze kannst du dann mit einem Macro verstecken:
#define new new(__LINE__,__FILE__,__FUNC__) //... int*i=new int; //... delete i;Es klappt nur solange niemand new per operator new aufruft
Der einzige Hacken an der Sache : Oft hilft es nicht wirklich zu wissen wie viel Speicher ein vector in welcher Methode anlegt.
-
Irgendwer schrieb:
__FUNC__ ist zwar nicht standard aber ein Debug Trick muss ja nicht portabel sein
Der C Standard kennt aber zumnindest __func__.
Irgendwer schrieb:
#define new new(__LINE__,__FILE__,__FUNC__)Das hatte ich auch mal so gemacht. Die Sache hat nur einen Haken, placement new funktioniert so nicht mehr. Dann kannst du nur eigene Bezeichner verwenden, was aber wiederum eine Anpassung der Software bedeutet.
-
Das valgrind Tool massif scheint genau das zu versprechen. Es kann den Speicherverbrauch der Funktionen auf dem Stack und dem Heap anzeigen.