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

observation on memory consumption

<< < (3/11) > >>

rickg22:
sorry, i don't... :(

by the way, i updated Codecompletion again today.

Michael:
Hello,

I have done some test with C::B (rev1884) about memory and remarked the following. At the start up, C::B memory requirement goes up to 27-28 MB. When I open the C::B project, C::B memory requirement goes up to 121-122 MB (with code completion). When closing the project (by using "close workspace"), the 50% of the memory used is returned. The same behavior happen without code completion, only that the used memory is much less.

IMHO there are some memory problems with both C::B itself and with code completion plugin.

Michael

thomas:

--- Quote from: Michael on January 27, 2006, 12:48:42 pm ---When closing the project (by using "close workspace"), the 50% of the memory used is returned. The same behavior happen without code completion, only that the used memory is much less.
--- End quote ---
This is normal behaviour. About 50% of the memory belongs to block allocated objects, these are never freed. Thus it always looks like there is a massive leak at first glance.

You cannot find out about memory leaks as simple as this (see my above post with the memory diagram). If you want to detect a memory leak by observing the total memory consumption, then you have to open/close the same project many times (10-20 times) as tiwag did.
If there are no memory leaks, you will still see that only 50% of the memory is freed, but if there is a leak (as it is the case), 50% of the peak will be freed every time, but the base will grow linearly.

Other options would be to
a) Compile wxWidgets in debug mode and run Code::Blocks from console. This will detect leaks of non-blockallocated objects.

b) Recompile Code::Blocks using the block allocator in debug mode. This will detect leaks of blockallocated objects. To do this, pass a positive integer as an additional template parameter to the classes which you want to observe:
  class Token  : public BlockAllocated<Token, 10000>
becomes
  class Token  : public BlockAllocated<Token, 10000, 1>

c) Use valgrind, but it is a lot easier to recompile wxWidgets in debug mode

Michael:

--- Quote from: thomas on January 27, 2006, 01:16:01 pm ---
--- Quote from: Michael on January 27, 2006, 12:48:42 pm ---When closing the project (by using "close workspace"), the 50% of the memory used is returned. The same behavior happen without code completion, only that the used memory is much less.
--- End quote ---
This is normal behaviour. About 50% of the memory belongs to block allocated objects, these are never freed. Thus it always looks like there is a massive leak at first glance.

You cannot find out about memory leaks as simple as this (see my above post with the memory diagram). If you want to detect a memory leak by observing the total memory consumption, then you have to open/close the same project many times (10-20 times) as tiwag did.
If there are no memory leaks, you will still see that only 50% of the memory is freed, but if there is a leak (as it is the case), 50% of the peak will be freed every time, but the base will grow linearly.

--- End quote ---

Thank you for your answer :). I have not open/close the same project 10-20 times, but it is sometimes already that I check C::B memory consumption when opening/closing the C::B project. Interesting is that after closing it and do some work with another application (e.g., IE, Word) and later checking the memory consumption of C::B, the value is of only 2-4 MB.

Anyway, I have tried C::B with Purify. You can find the report(s) in this topic.

Michael

tiwag:

--- Quote ---... but it is a lot easier to recompile wxWidgets in debug mode

--- End quote ---

to build CB with wx-debug libs is easy, but it doesn't run,

i've done this already but couldn't solve the never ending assertions ...

it seems, that any eventhandler inside CB throws assertions all the time - if this could be solved, we can debug the memory leaks

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version