Applikation wird langsam

flush

Hallo zusammen,

Ich teste mein aktuelles programm immer über nacht mit einem event recorder
(Zeichnet mouse-clicks auf und spielt sie 100000 mal ab). nach ca. 8 stunden
wird die applikation extrem langsam. könnte das die konsequenz von
memory-leaks sein?

danke & gruss
flush

Lutz

Du kannst nachsehen, indem du guckst, ob das Programm enorm viel Speicher frisst(z.B. im Taskmanager). Aber wenn du VC++ verwendest, bekommst du angezeigt, ob du Speicherlöcher hast.

Shade Of Mine

kann memleak sein, muss aber nicht.

es kann auch sein, dass du zuviele daten sammelst (zB unendlich viele undos) oder aehnlichen overhead durch die lange laufzeit erstellst.

ich habe zB heute so einen performance bug bei mir entdeckt: das generieren von temporaeren dateien stieg linear zur anzahl der dateien. wenn das programm also lange laeuft, erstellt es viele temporaere dateien und wird allein dadurch langsam (weil das generieren immer laenger dauert)

aehnliche sachen koennen es bei dir auch sein.

einfach mal einen profiler mitlaufen lassen, und dann anschauen wo die zeiten ansteigen.

Marc++us

Lutz schrieb:

Du kannst nachsehen, indem du guckst, ob das Programm enorm viel Speicher frisst(z.B. im Taskmanager). Aber wenn du VC++ verwendest, bekommst du angezeigt, ob du Speicherlöcher hast.

Das ist meines Erachtens eines der groessten Missverstaendnisse bzgl der Speicherlocherkennung... gerade bei Dauerlauftests.

Wobei das nix mit dem VC und dessen Erkennung zu tun hat, Codeguard und andere sind da auch machtlos.

Die Speicherlocherkennung bemerkt letztlich nur Fehler dieser Art:

int main()
{
   SomeClass* ptr = new SomeClass();
   return 0;
}

Aber gerade in Dauerlaeufen gibt's subtilere Probleme, naemlich dass Speicher allokiert wird, der am Programmende auch sauber freigegeben wird - aber den man bereits frueher freigeben koennte. Ich versuche das mal ein wenig zu skizzieren:

int main()
{
   list<SomeClass*> memlist;

   for (int i = 0; i < 999999999; ++i)
   {
      memlist.push_back(new SomeClass());
      // do some action with memlist
   }

   // nun tut das Programm ganz viele andere Dinge

   // nun iterator ueber memlist und delete(*it)
}

Eventuell haette man den Speicher gar nicht solange in memlist aufheben muessen, sondern haette viel frueher aufraeumen koennen - Speicherloecher gibt's in diesem Fall keine, aber trotzdem wird ein solches Programm (wenn man sich die for-Schleife als staendigen Aufruf alle paar Sekunden vorstellt) irgendwann langsam werden.

flush

guten abend,

vielen dank für eure hilfe.
im taskmanager habe ich als erstes nachgsehen, interessanterweise blieb der
memoryverbrauch unverändert (nach dem test, im ruhezustand, nach dem logout).
habe mit mpatrol nach speicherlöchern gesucht, allerdings ist mpatrol für meinen zweck wenig
geeignet, da mein programm mit plugins arbeitet (d.h. keine klasse wird exportiert, somit ist auch kein profiling mit mpatrol möglich...).

denke auch nicht das ich beim laden bzw. speichern von daten hänge, alle
diese vorgänge werden durch datenbank-plugins abgewickelt, welche auch
die langzeittests überstanden haben...

habe "von hand" nach memory-leaks gesucht und auch ein fatales entdeckt.
hoffe das dies nun der "übeltäter" ist

gruss

Wenn nicht, dann hilft einfach nur der Profiler. Beim AMD CodeAnalyst kannst du beispielsweise das Aufzeichnen anhalten. Wenn dein Programm dann langsam wird, kannst du ihn wieder dazuschalten und dann hast du genau für diese langsam-phase die Aufzeichnen. Das wird sicherlich einige Klarheit bringen.

flush

habe leider den bug nicht fixen können. nun muss ich wohl doch einen
profiler brauchen... habe mir den codeanalyst heruntergeladen,
allerdings komme ich nicht mit dem zurecht... denke es liegt an meinem
intel prozessor kennt jemand von euch andere gute profiler?

Zeitmessungen kannst du mit dem CodeAnalyst auch mit Intel-Prozessoren durchführen. Kostenlose gute gibt es nicht viel andere. Und einfachere auch nicht.

flush

brauche ich keine simulation um die aufzeichnung anhalten zu können?