observation on memory consumption

[Michael]

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

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.

Thank you for your explanation . Anyway, the total amount of memory still tends to grow (it is what I have observed). But this growth is difficult to spot, becuase it is just a matter of KB (before it was MB). 

Michael

[Der Meister]

Another thing is: valgrind reported much more memory leaks than my patch solved. At least one more should be removed by thomas' patch (I did not test it yet - using valgrind needs some time; for example Code::Blocks needs about three minutes to start on my 2,4GHz Pentium 4) but others remain and I fear that we can't solve all of them. Some seem to be the fault of wxGTK or even gtk or Xlib... Anyway, as long as they are not too big and only appear once in the complete livetime of the Code::Blocks process they should not be a real problem.

[Michael]

Another thing is: valgrind reported much more memory leaks than my patch solved. At least one more should be removed by thomas' patch (I did not test it yet - using valgrind needs some time; for example Code::Blocks needs about three minutes to start on my 2,4GHz Pentium 4) but others remain and I fear that we can't solve all of them. Some seem to be the fault of wxGTK or even gtk or Xlib...

Purify does the same . The expanded report is more than 13MB (txt file). In this report are reported not only memory leaks ("real" and potential), but also null pointers, invalid pointers, exceptions, and so on related to C::B and plugins, windows libraries and wxWidgets library. With some time and patiente it would be possible to get something useful. 

Anyway, as long as they are not too big and only appear once in the complete livetime of the Code::Blocks process they should not be a real problem.

Yes, I agree. It would have no sense to try to solve all the possible memory leaks.

Michael

[thomas]

The point is that the peak memory consumption does not grow any more.


Compare this to any of the above recordings:



There are very clearly remaining leaks... there is obviously an upward tendency, but the peak allocation (which is what matters) really does not change so much.

EDIT:
It is interesting to compare the shapes of the individual spikes. You can see that the more often you open and close a project, the longer it takes to allocate memory, and there are obviously some kind of garbage collections or reorderings taking place in the middle.
I assume this is because the heap is getting so heavily fragmented with time. This was one reason why we made cbEvents and Tokens block-allocated. Those objects are constantly allocated and destroyed (many thousand times), and block-allocating them prevents heap fragmentation.

[Michael]

I have done a small graphic about a fast test I have done. It looks like yours, but I think that I should have taken more sample values for a better distribution line. I will try tomorrow to do a better graph.

Michael

[EDIT] Value 1 is starting C::B, value 2 is opening C::B project, value 3 closing the workspace and so on. Vallues are expressed in KB.


[attachment deleted by admin]

[rickg22]

Good news people, i got rid of that nasty fullnames tree, and the contribplugins uses max 290 MB

[Michael]

Good news people, i got rid of that nasty fullnames tree, and the contribplugins uses max 290 MB

You have done a good job . I have tried C::B rev1893 with Code Completion (full options) and all the other plugings and it seems the C::B does not more require 100 MB for opening the C::B project. The graph attached can demonstrate it. Value 1 is starting C::B, value 2 is opening C::B project, value 3 is closing the workspace and so on. Vallues are expressed in KB.

Michael


[attachment deleted by admin]