Why is "Show uses" sometimes so slow?

Alexandre Courbot gnurou at gmail.com
Wed May 30 14:07:24 UTC 2012

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
> the memory consumption might still be higher due to memory fragmentation.
> That said, I wonder why the parser would still kick in sometimes - have
> 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
> 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.

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

More information about the KDevelop-devel mailing list