Problem beim Speicher freigeben



  • hi,

    ich habe ein kleines Testprogramm geschrieben in dem ich 768 STL-Listen mit insgesamt ca. 2millionen einträgen verwende. Der Algorithmus läuft in wenigen sekunden durch. Das komische ist nun dass er beim deallozieren also quasi beim verlassen dre fzunktion fast 5 minuten braucht um den speicher wieder freizugeben.

    Ich habe es mit visual studio 2008 getestet.
    Hier der code:

    #include <list>
    #include <iostream>
    
    using namespace std;
    
    struct TestStruct
    {
    	int a;
    	int b;
    	int c;
    };
    
    void testFunc()
    {
    	list<TestStruct> testList[256 * 3];
    	TestStruct ts;
    
    	for(int jx = 0; jx < 308; ++jx)
    	{
    		for(int jy = 0; jy < 200; ++jy)
    		{
    			for(int c = 0; c < 3; ++c)
    			{
    				for(int ij = 0; ij < 14; ++ij)
    				{
    					testList[0].push_back(ts);
    				}
    			}
    		}
    	}
    
    	cout<<"gebe Speicher frei..."<<endl;
    }
    
    int main()
    {
    	cout<<"start"<<endl;
    	testFunc();
    	cout<<"fertig"<<endl;
    	getchar();
    
    	return 0;
    }
    

    Wie kann es sein dass er so extrem lange zum speicher freigeben braucht?
    Kann es sein dass es an der STL-Liste liegt?
    Btw. ich habe es auch schon mit einer Liste von Zeigern probiert, da gab es auch keinen Geschwindigkeitsunterschied.


  • Mod

    Kann ich absolut nicht nachvollziehen (gcc ohne jegliche Optimierungen). Verwendest du möglicherweise eine Debugimplementierung der STL?



  • Ich habe einfach nur visual c++ installiert und mehr nicht.
    Wenn ich das Program im Release build ausführe ist es auch so langsam.



  • _nico schrieb:

    Wenn ich das Program im Release build ausführe ist es auch so langsam.

    MS baut afaik noch ne "sichere Implementierung" der Iteratoren und von allem möglichen ein. Schau mal in der Doku nach, es gibt da ein Flag _SECURE_STL oder sowas.



  • pumuckl schrieb:

    _nico schrieb:

    Wenn ich das Program im Release build ausführe ist es auch so langsam.

    MS baut afaik noch ne "sichere Implementierung" der Iteratoren und von allem möglichen ein. Schau mal in der Doku nach, es gibt da ein Flag _SECURE_STL oder sowas.

    es wird aber weniger daran liegen als an der debug-runtimelib(würd ich jz zumindest mal ganz frech behaupten wollen^^)
    was passiert, wenn du die releaseversion der *.exe von hand ausführst?
    dauert es dann auch so lang?
    es wird intern immerhin ja auch (mind.) 2'500'000 mal delete aufgerufen - bei 5 Minuten würde ein delete also 0.00012Sekunden dauern - kann ich mir in der Debug-Runtime durchaus vorstellen...

    bb



  • Wenn ich die exe der release version ausführe läuft es sehr schnell.
    Scheint wohl an der debugruntime von visual studio zu liegen.

    Naja vielen dank für die antworten 😉



  • _nico schrieb:

    Wenn ich die exe der release version ausführe läuft es sehr schnell.
    Scheint wohl an der debugruntime von visual studio zu liegen.

    Naja vielen dank für die antworten 😉

    ich glaub, die kann man auch iwo im vs deaktivieren - vermutlich bei den Profilen, aber vll auch in Projektoptionen - wenn dir so ist, kannst du ja ma suchen und hier posten, dann kann ich mir das ma bookmarken und weiß gleich, wie es aus geht, falls ich es auch mal brauchen sollte xD

    bb



  • Einfach "Starten ohne Debuggen" benutzen (Strg+F5)..


Anmelden zum Antworten