<p><br>
On May 30, 2012 8:54 PM, "Milian Wolff" <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br>
> This is partially due to keeping the AST in memory (you should use<br>
> AllDeclarationsContextsAndUses) of referenced topcontexts. Once that is fixed,<br>
> the memory consumption might still be higher due to memory fragmentation.<br>
><br>
> That said, I wonder why the parser would still kick in sometimes - have the<br>
> underlying files changed and thus need to be reparsed? If not, this smells<br>
> like a bug that should be investigated.</p>
<p>I actually tried with AllDeclarationsContextsAndUses after <br>
realizing the AST would probably not be useful anyway. Memory footprint was much more reasonnable, but still the parser kicked in despite the files not having changed - actually I was surprised to also see that the disk storage was only doubled compared to the default parameter.</p>

<p>For the sake of the demo, I can take advantage of the fact that subsequent searches are faster by doing the uses lookup ahead of time - that seems to work well. But this is definitely an area I will want to improve.</p>

<p>> The bottle neck is not in restoring cached data imo, but rather high lock<br>
> contention and thus abysmal performance on multicore systems paired with high<br>
> code (and problem) complexity and thus huge number of instructions required to<br>
> update a file.</p>
<p>Oh yeah, the unique lock for the whole DUChain. The kernel had the BKL (Big Kernel Lock) in its time too. :) Indeed if contexts could be locked individually that would probably make things more parallel-friendly (although in my experience the current parser scales rather well up to the number of cores you have on your machine).</p>

<p>Thanks for the comments anyway, they made things much clearer.</p>
<p>Alex.</p>