Speicher freigeben extrem langsam

Nexus

Dein Code ist ein ziemliches Gewirr. Wieso leitest du die Konstruktionen weiter und erzeugst jeweils einzelne Instanzen mit new ? Die Gefahr für Memory Leaks steigt damit stark.

Aber grundsätzlich finde ich den Code sehr unübersichtlich. Die Aufgaben sind völlig willkürlich verteilt. Nur schon der Konstruktor der Klasse3, der Speicher vorreservieren soll, welcher wieder in Klasse2 gefüllt wird. Durch das public ist überhaupt keine Kapselung vorhanden.

Michi78 schrieb:

Muss doch bei nem vector von pointern das manuell verwalten, sonst gibt er den Speicher doch nicht frei, oder? Bin bei meinen Berechnungen bei ca 1,5GB Speciherbedarf, den ich wieder frei geben muss um weitere Berechnungen zu machen, sonst würd ich halt nur Speicher holen.

Hatte es zuerst ohne Pointer, das war aber noch langsamer...

Das glaube ich nicht. Wie gesagt ist es meistens schneller, wenn viel Speicher auf einmal allokiert/deallokiert werden kann.

Kannst du dein Problem nicht auf einen übersichtlichen kurzen Code reduzieren, der dem beschriebenen Verhalten immer noch gerecht wird?

unskilled

Nexus schrieb:

Michi78 schrieb:

Muss doch bei nem vector von pointern das manuell verwalten, sonst gibt er den Speicher doch nicht frei, oder? Bin bei meinen Berechnungen bei ca 1,5GB Speciherbedarf, den ich wieder frei geben muss um weitere Berechnungen zu machen, sonst würd ich halt nur Speicher holen.

Hatte es zuerst ohne Pointer, das war aber noch langsamer...

Das glaube ich nicht. Wie gesagt ist es meistens schneller, wenn viel Speicher auf einmal allokiert/deallokiert werden kann.

hum? er hat aber keine einfache möglichkeit, das auf einmal zu allokieren/deallokieren - er müsste eben wie gesagt den weg über den memory pool gehen - das sollte zwar nicht unendlich viel arbeit sein, aber konzeptionell ist es bestimmt nich gerad einfach (am stück? eher nich bei 1,5GB -> blockgröße?)
er muss alle news durch placement news ersetzen oder direkt nen eigenen allokator schreiben und den 3 klassen diesen mitgeben...

würde aber einiges für die lsg sprechen, denk ich ^^

bb

Michi78

Sorry an alle für den Code-Wirrwar, bin halt schon froh wenn der Rechner das macht, was er machen sollte... Vielen Dank aber für eure Ideen.

unskilled schrieb:

fragt sich nur, ob bei einer simulation 30 sekunden so groß ins gewicht fallen...

naja, bei dem Beispiel werden ca 50MB Speicher genutzt. Bei 1,5 GB, den ich ca 2-3 mal freigeben müsste, warte ich dann schon eine ganze Weile auf die Speicher-Putzkolonne...

unskilled schrieb:

er hat aber keine einfache möglichkeit, das auf einmal zu allokieren/deallokieren - er müsste eben wie gesagt den weg über den memory pool gehen

Das seh ich ähnlich, denn ich weiss nunmal nicht wieviel ich brauche da die Länge der Vektoren zufällig ist und sich in jeder Simulation ändert. Wie würde denn das mit dem Memory-Pool prinzipiell gehen, könntest mir das kurz erklären???

unskilled schrieb:

aber es muss ja auch 300000x delete aufrufen

Was ich halt nicht versteh ist, wieso 300000 mal den Destruktors aufzurufen so extrem viel länger dauert als 300000 mal den Konstruktor.

Hoffe, irgendwer hat noch Ideen oder Anregungen...

Beste Grüsse

Michael

Badestrand

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

Michi78 schrieb:

Wie würde denn das mit dem Memory-Pool prinzipiell gehen, könntest mir das kurz erklären???

Selber machen lohnt sich nicht. Schau mal hier:
http://www.boost.org/doc/libs/1_38_0/libs/pool/doc/index.html

unskilled

Badestrand schrieb:

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

Oo
welchen? wie/wo/... ?

ich habs doch extra alles ausprobiert (und hab VS08)

bb

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.