observation on memory consumption

[thomas]

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.

This is a Windows malfunction. The Windows marketing FUD for this is "working set optimization" or something, but it is really a malfunction.

If you minimize an application, Windows purges most of its memory pages, no matter whether it needs the RAM or not. The "reasoning" behind this is that it is good to have a lot of free RAM, but in fact it only proves that they don't know the difference between "nano" and "milli". Purging memory pages when you don't need to is really, really stupid.

[mandrav]

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

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

Strange, I have removed all the assertions I could find (last week, IIRC). Maybe it's been some time since you tried it?

[tiwag]

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

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

Strange, I have removed all the assertions I could find (last week, IIRC). Maybe it's been some time since you tried it?

thx for the info,
last time i did was about 3 weeks before ;-)

[thomas]

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

Well, I may have been a bit hasty in my judgement here. In fact, it is not easy to get it to work, at all. :lol:

[tiwag]

i just finished with building a WXDEBUG build of C::B  (added __WXDEBUG__ to Project's Compiler #definitions, and changed custom variable WX_SUFFIX=ud )

it runs, but crashes when attempting to load CodeBlocks.cbp

but a small console project, which i have built with the NewProject generator, loads and works without problems ;-)
not all hope is lost ...

[rickg22]

Thomas, I have a request... are you sure you can't make a way to free VERY LARGE unused blocks of memory with your blockallocator? i.e. we have tokens allocated in groups of 10,000. Could you make it so that when all the tokens of a specific block have been freed, the block would be released automatically? This would spare us having 600Megs of unused memory making up space after we close the contribs workspace... ¬¬

[takeshimiya]

Just to make sure I'm not doing anything wrong:
I open the contribs workspace with codecompletion activated. I don't do absolutely nothing, and the memory and cpu increases makes the system almost unuseable.

This is the graph.

[attachment deleted by admin]

[mandrav]

Is this just me, or is code-completion crashy today?
Some times it will crash on project load, some other times it will crash on project close and other times (twice) has hung with 50% cpu usage indefinetely...

And when I say crash, I mean it just disappears. No error message (windows or otherwise), nothing.

[takeshimiya]

Yes, codecompletion is very crashy, but he is not alone, debugger is also crashy (not that much like codecompletion, but...).

But codecompletion is really unuseable, it eats all the cpu, all the ram, and then, probably, crashes.


EDIT: when I mean that debugger is crashy, I mean, I only do a right-click on the watches panel (even without the debugger running), click on Add watch, and "it just disappears. No error message (windows or otherwise), nothing."

[mandrav]

EDIT: when I mean that debugger is crashy, I mean, I only do a right-click on the watches panel (even without the debugger running), click on Add watch, and "it just disappears. No error message (windows or otherwise), nothing."

For this, you should update more often before complaining

[tiwag]

Is this just me, or is code-completion crashy today?...

the only crash i got today related to codecompletion was when i ran the wxdebug-version of CB ;-)

[takeshimiya]

For this, you should update more often before complaining

Mm, I'm at Rev.1887 which is the latest. That means that anonymous SVN is lagging?

[mandrav]

That's strange because it really crashed earlier today but that was an error in the script bindings which I fixed. I have been debugging all day since that time...

Will look at it later again...

[takeshimiya]

Just in case you can't reproduce it, I attach the backtrace.

[attachment deleted by admin]

[thomas]

Thomas, I have a request... are you sure you can't make a way to free VERY LARGE unused blocks of memory with your blockallocator? i.e. we have tokens allocated in groups of 10,000. Could you make it so that when all the tokens of a specific block have been freed, the block would be released automatically? This would spare us having 600Megs of unused memory making up space after we close the contribs workspace... ¬¬

sizeof(Token) == 140, thus 600 MB == 4,491,264 Tokens. If you really allocate that many tokens, then you should think about looking for a serious bug in the parser

But now seriously: we already talked about this idea of releasing blocks, and I already told you once: this is a really bad idea. Tokens, or their allocation is not the problem we're trying to solve. Starting to tweak the allocator will get you absolutely nowhere, it will only add to overhead.

Parsing CodeBlocks.cbp produces 79,000 tokens with "everything turned on". The block allocator allocates 80,000 tokens (10.68 MB) for these.

However, if you look at the actual memory consumption, you get figures like this:
Code::Blocks flat: 11.0 MB
Code::Blocks loading CodeBlocks.cbp with code completion turned off: 11.6 MB
Code::Blocks loading CodeBlocks.cbp with code completion turned on: 85.6 MB

Code completion uses up 74 MB, but only 10.68 MB are assigned to tokens. So where do the other 63.62 MB go? Do you see my point?

Adding the ability to release free blocks would make the allocator a lot more complicated and would mean a noticeable increase (read "noticeable " as "about 100%") in execution time for allocations and deallocations, and there is really no reason why we need it. The memory consumed by tokens is very acceptable compared to other structures. Also, the memory is not "lost", but reused when more objects are allocated.