Why is "Show uses" sometimes so slow?

[Andreas Pakulat]

Hi,

On Tue, May 29, 2012 at 3:18 AM, Alexandre Courbot <gnurou at gmail.com> 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.
> :)
>
> 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.
>

It already is all stored to disk, also the information for uses. But it
also needs to be loaded from disk again (at least to a certain extent) when
showing the uses-info etc. Since this is probably not very little data, you
end up with a bigger memory-footprint.

This is one of the classic problems in programming, often you can  gain
speed at the expense of requiring more memory or vice-versa. But seldomly
there's a way to get both down considerably.

Andreas

PS: I'm not saying there's no way to improve the situation you see, since I
didn't do any kind of performance measuring on those parts ever, but I do
know that Milian did spend quite some time on such things so it at least
not very easy to find areas to improve.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120529/59011c45/attachment.html>