Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

observation on memory consumption

<< < (9/11) > >>

sethjackson:

--- Quote from: Michael on January 28, 2006, 01:38:32 pm ---Hello,

I have remarked something about memory leaks. I have tried to open/close several times the C::B project with all the plugins and I have remarked that each time I lose around 2MB. For example if at beginning I have X=2MB, then after opening and closing C::B project I have X=4MB. If I repeat I will have X=6MB and so on. Then I have tried without plugins. I have switched off all the plugins in the 2menage plugins". I have observed the same behavior. X=2MB, then X=4MB, then X=5MB, then X=7MB and so on. Practically, the memory needed to open the C::B project is not released when I close the workspace.

Hope this could help :).

Michael

[EDIT] Sorry I have forgotten to say that I have used rev1889.


--- End quote ---

I thought thomas siad it was the start here page or something. Although the memory for project opening/closing could be a problem too.......

thomas:

--- Quote from: sethjackson on January 28, 2006, 02:28:56 pm ---I thought thomas siad it was the start here page or something.
--- End quote ---
Well, that does not mean there can't be others...

I believe that I found and fixed the leak regarding project files. I still have to test it a couple of times before committing though.
This leak is wxWidget's fault, in my opinion. DeleteNode() suggests that this deletes the node and the data, even more so as the documentation to RemoveNode() says "you have to free the object yourself". I replaced the DeleteNode() with the code sample from the wxList documentation (basically just deletes the node and the object), and it seems that the memory leak is gone.

I get this now when opening/closing the Code::Blocks project (compiler and debugger plugin active, all others disabled, start_here page disabled)




--- Code: ---Index: sdk/cbproject.cpp
===================================================================
--- sdk/cbproject.cpp (revision 1889)
+++ sdk/cbproject.cpp (working copy)
@@ -989,24 +989,18 @@
             return false;
 
  // now free the rest of the project files
-    int count = m_Files.GetCount();
     Manager::Get()->GetEditorManager()->HideNotebook();
     FilesList::Node* node = m_Files.GetFirst();
     while(node)
     {
         ProjectFile* f = node->GetData();
-        if (Manager::Get()->GetEditorManager()->Close(f->file.GetFullPath(),true))
-        {
-            FilesList::Node* oldNode = node;
-            node = node->GetNext();
-            m_Files.DeleteNode(oldNode);
-            --count;
-        }
-        else
-            node = node->GetNext();
+        Manager::Get()->GetEditorManager()->Close(f->file.GetFullPath(),true);
+        delete f;
+        delete node;
+        node = m_Files.GetFirst();
     }
     Manager::Get()->GetEditorManager()->ShowNotebook();
-    return count == 0;
+    return true;
 }
 
 bool cbProject::SaveAllFiles()
--- End code ---

thomas:
Memory consumption now seems to be almost constant, possibly asymptotic (with code completion disabled).

With code completion enabled, the base memory still grows linearly, but the peak stays constant (that is probably an effect of the block allocator). There is also quite noticeable heap fragmentation (visible by the dull peaks and the lessened inclination of the curve after opening and closing a large project 15-20 times. I haven't had the time to test what happens when the base memory grows as high as the peak, have to go out now... :(

Michael:
Hello,

I have performed some tests with the rev1891 and I have remarked the good works of the devs&all concerning the memory leaks :D. Unfortunately, the behvior that I have observed before it is not fully gone away.

I have tried C::B without any plugins and opened/closed several times the C::B project. After closing the project, the memory is used is returned to the system, but not always and when its amount is generally less than what it was used. Sometimes the memory got accumulated and later returned to the system. This behavior was relatively chaotic and difficult to correctly describe it (sorry). Before it did not returned the memory used when opening a project (the amount was relatively constant, i.e., 1-2MB). Now, the amount of memory used to open the project is sometimes 100-200 kb, sometimes less.

IMHO, there is still something that keeps the memory and does not or not always return it to the OS.

Michael 

thomas:

--- Quote ---IMHO, there is still something that keeps the memory and does not or not always return it to the OS.
--- End quote ---
Lol, at the risk of repeating myself... the block allocator never returns allocated memory to the OS, this is normal.

Only objects that are allocated via standard operator new are returned to the OS when they are deleted. That is for example the case for classes like wxFileName, or wxTextCtrl, but it is not true for cbEvent, Token, ProjectFile, ProjectBuildtarget, and maybe a couple of others.

Thus, it is correct that not all memory is freed, it must not be. The important point, however, is that the memory is reused, so if you open the same project 20 times (and even if you open/close different projects several times), the total amount of memory has to stay the same as long as your total memory requirement is not higher.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version