Speicher freigeben extrem langsam

volkard

Badestrand schrieb:

Ich hab den Code gerade mal ausprobiert, dauert bei mir alles exakt 0 Sekunden, mit VS05.

ja, der kumpel kann testprogramme der art

int* arr=new int[...];
//schreib und lies in arr wie du magst
delete[] arr;

erkennen und wegoptimieren.
man muß generell bei messprogrammen immer dafür sorgen, daß alle operationen in einer ergebniszahl kumukliert werden und dann zum beispiel mit cout.

unskilled

so hab ichs ja nu au extra geschrieben... ~~

bb

Nexus

Gerade habe ich etwas Ähnliches versucht (unter MSVC++ 2008 Express). Wenn ich auf "Starten" klicke, dauert die Deallokation sehr lange. Benutze ich "Starten ohne Debuggen", geht es sehr schnell, Allokation und Deallokation dauern ungefähr gleich lange (beide sehr kurz). Das gilt auch für direktes Starten der .exe-Datei, also sobald keine Debugging-Umgebung mehr vorhanden ist.

Ich habe auch ein wenig mit dem AMD CodeAnalyst rumprobiert, da brauchten Aufrufe von operator new und operator delete mit Abstand am wenigsten Zeit. Allerdings weiss ich nicht, wie viel da geinlinet wird, und mit Assembler kenne ich mich zu wenig aus...

Badestrand

volkard schrieb:

man muß generell bei messprogrammen immer dafür sorgen, daß alle operationen in einer ergebniszahl kumukliert werden und dann zum beispiel mit cout.

In einer von unskilleds Varianten wird ja die Anzahl der Dtor-Aufrufe mitgezählt und am Schluss ausgegeben, der Assembler-Code sieht auch nicht so aus, als ob alles wegoptimiert werden würde

Andererseits hab ich grad mal geschaut, bei mir verbraucht's im Taskmanager auch nur 36 MB, ist ja schon was anderes als die 1,5 GB von denen der TO sprach.

unskilled

Badestrand schrieb:

volkard schrieb:

man muß generell bei messprogrammen immer dafür sorgen, daß alle operationen in einer ergebniszahl kumukliert werden und dann zum beispiel mit cout.

In einer von unskilleds Varianten wird ja die Anzahl der Dtor-Aufrufe mitgezählt und am Schluss ausgegeben, der Assembler-Code sieht auch nicht so aus, als ob alles wegoptimiert werden würde

Andererseits hab ich grad mal geschaut, bei mir verbraucht's im Taskmanager auch nur 36 MB, ist ja schon was anderes als die 1,5 GB von denen der TO sprach.

Ich seh gerade, dass es bei mir auch max. 50MB sind - aber es sah so aus, als ob er zwischendrin immermal was wieder freigibt - er optimiert halt einfach zu sehr -.- Zu lange dauern tuts trotzdem ^^
der to kann sich ja ma melden und sagen, wie es mit nem memory-pool aussieht...

bb

Nexus

unskilled schrieb:

Zu lange dauern tuts trotzdem ^^

Seid ihr jetzt sicher, dass ihr ohne Debug-Laufzeitumgebung startet (auch im Release-Modus)? Bei mir hat das sehr viel ausgemacht.

unskilled

Nexus schrieb:

unskilled schrieb:

Zu lange dauern tuts trotzdem ^^

Seid ihr jetzt sicher, dass ihr ohne Debug-Laufzeitumgebung startet (auch im Release-Modus)? Bei mir hat das sehr viel ausgemacht.

tzz
natürlich hab ichs im release-mode compiliert und getestet...
schnell (<1sec) gings bei mir erst, nachdem ichs nach dem (release-)durchlauf (zusätzlich) nochmal mit dem profiler optimiert hatte - aber der wird ja mitbekommen haben, dass er sämlichen new/delete-kack weglassen kann - und deshalb kann man die werte wohl auch nicht zum vergleich nehmen...

bb

Nexus

unskilled schrieb:

tzz
natürlich hab ichs im release-mode compiliert und getestet...

Natürlich. Es ging aber nicht um Release- vs. Debug-Mode, sondern ums Starten der Laufzeitumgebung. Und bei MSVC++ ist das in beiden Konfigurationen möglich. Wie gesagt hat das bei mir den Grossteil der Zeit ausgemacht.

Da ich das nur gut meinte und auf eine mögliche Fehlerquelle hinweisen wollte, besteht auch kein Grund, so zu antworten.

Fragt doch erst mal was das Programm machen soll. Es ist sehr wahrscheinlich, dass es da ne bessere Lösung gibt als diesen wirren Code zu optimieren.

Michi78

Vielen Dank für eure Hilfe

Nexus schrieb:

Wenn ich auf "Starten" klicke, dauert die Deallokation sehr lange. Benutze ich "Starten ohne Debuggen", geht es sehr schnell, Allokation und Deallokation dauern ungefähr gleich lange (beide sehr kurz)

Das hat bei mir auch den Effekt, dass es das gesamte Programm innerhalb von 0 Sek ausführt. Hatte vorher immer mit "Starten" (im Release-Mode) das Programm ausgeführt und war mir dessen nicht bewusst... So ganz klar ist es mir allerdings nicht, wobei ich froh bin, dass es nun wie gewünscht funktioniert und den Speicher entsprechend freigibt.

Badestrand schrieb:

Andererseits hab ich grad mal geschaut, bei mir verbraucht's im Taskmanager auch nur 36 MB, ist ja schon was anderes als die 1,5 GB von denen der TO sprach.

Die 1,5 GB sind in dem finalen Programm zu erwarten. Das angegebene Beispielprogramm nutzt grob 50MB, sollte ja nur verdeutlichen dass dann 30 Sek Speicher-Freigebezeit pro 50MB bei 1,5 GB schon ne andere Dimension annehmen würde.

unskilled schrieb:

der to kann sich ja ma melden und sagen, wie es mit nem memory-pool aussieht...

memory-pool hat irgendwie auch nichts gebracht bei der performance (mit der Version "Starten")

Werd jetzt erstmal mit der Version "Starten ohne Debuggen" weiterarbeiten, da läuft das Programm ja entsprechend zügig durch.

Merci nochmals

Nexus

Michi78 schrieb:

Das hat bei mir auch den Effekt, dass es das gesamte Programm innerhalb von 0 Sek ausführt. Hatte vorher immer mit "Starten" (im Release-Mode) das Programm ausgeführt und war mir dessen nicht bewusst... So ganz klar ist es mir allerdings nicht, wobei ich froh bin, dass es nun wie gewünscht funktioniert und den Speicher entsprechend freigibt.

Gut, dass es nun funktioniert.

Ich hätte auch nie gedacht, dass die Debug-Umgebung zu so langer Verzögerung führt. Wahrscheinlich liegt es an zusätzlichen Sicherheits-Checks oder Debug-Informationen für Speicheroperationen...

Shade Of Mine

Nexus schrieb:

Ich hätte auch nie gedacht, dass die Debug-Umgebung zu so langer Verzögerung führt. Wahrscheinlich liegt es an zusätzlichen Sicherheits-Checks oder Debug-Informationen für Speicheroperationen...

Es wird eine Liste geführt wann wo wieviel Speicher allokiert wurde und wann wo wie wieviel Speicher freigegeben wurde.

Wenn du pech hast, hast du dann auch noch immer schön pagefaults drinnen beim delete - je nach implementierung halt.