Author Topic: observation on memory consumption  (Read 73785 times)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: observation on memory consumption
« Reply #45 on: January 28, 2006, 09:54:04 pm »
Quote
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

Offline Der Meister

  • Regular
  • ***
  • Posts: 307
Re: observation on memory consumption
« Reply #46 on: January 28, 2006, 10:03:20 pm »
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.
Real Programmers don't comment their code. If it was hard to write, it should be hard to understand.
Real Programmers don't write in BASIC. Actually, no programmers write in BASIC, after the age of 12.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: observation on memory consumption
« Reply #47 on: January 28, 2006, 10:16:22 pm »
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

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: observation on memory consumption
« Reply #48 on: January 28, 2006, 10:17:31 pm »
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.
« Last Edit: January 28, 2006, 10:24:15 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: observation on memory consumption
« Reply #49 on: January 28, 2006, 10:36:20 pm »
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]
« Last Edit: January 28, 2006, 10:39:06 pm by Michael »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: observation on memory consumption
« Reply #50 on: January 29, 2006, 03:59:32 am »
Good news people, i got rid of that nasty fullnames tree, and the contribplugins uses max 290 MB :)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: observation on memory consumption
« Reply #51 on: January 29, 2006, 01:57:46 pm »
Good news people, i got rid of that nasty fullnames tree, and the contribplugins uses max 290 MB :)

You have done a good job :D. 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]