Why is "Show uses" sometimes so slow?

[Milian Wolff]

On Tuesday 29 May 2012 10:18:42 Alexandre Courbot wrote:
> On Tue, May 29, 2012 at 3:10 AM, Milian Wolff <mail at milianw.de> wrote:
> > Have you tried to increase "Language Support" -> "Project Parsing" ->
> > "Minimum project size for simplified parsing"? Afaik that should in
> > theory trigger a full load - if not I'll have to check the code again.
> 
> It is already set to 100.000 files, which is much more than a typical
> kernel configuration (typically 6500-10000 files for embedded ARM
> configs). So I don't think simplified parsing takes place here.
> 
> I have tried replacing some VisibleDeclarationsAndContexts by
> AllDeclarationsContextsUsesAndAST in the default arguments provided to
> the parser methods of kdevplatform. It seems to have made uses search
> more instant (although sometimes the background parser would still
> kick in), at the cost of a slower initial parsing (expected) and, more
> concerning, a 2.1Gb memory use against 400-500Mb when regular parsing
> is done. So I think it might not be the best solution to my problem.

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 am trying to see how DUChains are stored on disk, as I think this
> might be where the key to best performance resides - store as much
> indexed information on disk as possible and just retrieve it instead
> of computing it on demand. Will probably not make it for the demo
> though, so any other suggestion is welcome.

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.

bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120530/2720d155/attachment.sig>