Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
observation on memory consumption
Michael:
--- Quote from: thomas on January 27, 2006, 08:06:59 pm ---Code::Blocks loading CodeBlocks.cbp with code completion turned on: 85.6 MB
--- End quote ---
In my case it goes up to more than 120 MB (around 110000 tokens in a bit more than 1100 files). Before it was a bit more than 90 MB (a bit more than 90000 tokens in a bit more than 900 files). This increase was remarked since rickg22 commited some code completion fixes. To be noted is that I have all the options selected in code completion (cache included).
Michael
thomas:
--- Quote from: Michael on January 27, 2006, 08:24:08 pm ---In my case it goes up to more than 120 MB (around 110000 tokens in a bit more than 1100 files).
--- End quote ---
That's 14.68 MB in tokens versus 108 MB in "something else", so it is even worse.
Michael:
--- Quote from: thomas on January 27, 2006, 08:27:59 pm ---
--- Quote from: Michael on January 27, 2006, 08:24:08 pm ---In my case it goes up to more than 120 MB (around 110000 tokens in a bit more than 1100 files).
--- End quote ---
That's 14.68 MB in tokens versus 108 MB in "something else", so it is even worse.
--- End quote ---
Yes. May be rickg22's fixes have caused code completion to read more files, which explains the higher number of tokens and of memory used. I am trying to continue the tests with Purify, but now I got Purify crashing when running C::B with just the option "memory leaks"... :?
Michael
rickg22:
Well, besides the token i have some extra search structures, but the search tree only uses memory linear to the number of tokens added, and it's less than the token names.
Thomas, are you POSITIVELY sure about the space used per token? Because each token includes an amount of of strings, and the space used by the strings is not insignificant... I may, however, delete an extra search tree on the tokens' fullnames...
Yiannis: I haven't noticed crashes with codecompletion, please post stack traces - it's probably due to using more than one thread at the same time (before my fixes it only used one thread), so maybe there are critical sections missing. Maybe the reason for CB not crashing on my machine is that I have a single-core... :-/
thomas:
--- Quote ---Thomas, are you POSITIVELY sure about the space used per token? Because each token includes an amount of of strings, and the space used by the strings is not insignificant... I may, however, delete an extra search tree on the tokens' fullnames...
--- End quote ---
The space used by strings is allocated separately, it is not part of the Token object, and the block allocator has no control over it. In fact, if the string buffer were part of the object, the block allocator would crash, as it can only handle objects of fixed size with no derived virtual descendants.
sizeof(Token) is positively 140 in revision 1887 (used to be 124 in revision 1421).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version