Why is "Show uses" sometimes so slow?

[Alexandre Courbot]

On May 30, 2012 8:54 PM, "Milian Wolff" <mail at milianw.de> wrote:
> This is partially due to keeping the AST in memory (you should use
> AllDeclarationsContextsAndUses) of referenced topcontexts. Once that is
fixed,
> the memory consumption might still be higher due to memory fragmentation.
>
> That said, I wonder why the parser would still kick in sometimes - have
the
> underlying files changed and thus need to be reparsed? If not, this smells
> like a bug that should be investigated.

I actually tried with AllDeclarationsContextsAndUses after
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.

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.

> The bottle neck is not in restoring cached data imo, but rather high lock
> contention and thus abysmal performance on multicore systems paired with
high
> code (and problem) complexity and thus huge number of instructions
required to
> update a file.

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).

Thanks for the comments anyway, they made things much clearer.

Alex.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120530/7d532291/attachment.html>