Hi,<br><br><div class="gmail_quote">On Tue, May 29, 2012 at 3:18 AM, Alexandre Courbot <span dir="ltr"><<a href="mailto:gnurou@gmail.com" target="_blank">gnurou@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, May 29, 2012 at 3:10 AM, Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br>
> Have you tried to increase "Language Support" -> "Project Parsing" -> "Minimum<br>
> project size for simplified parsing"? Afaik that should in theory trigger a<br>
> full load - if not I'll have to check the code again.<br>
<br>
</div>It is already set to 100.000 files, which is much more than a typical<br>
kernel configuration (typically 6500-10000 files for embedded ARM<br>
configs). So I don't think simplified parsing takes place here.<br>
<br>
I have tried replacing some VisibleDeclarationsAndContexts by<br>
AllDeclarationsContextsUsesAndAST in the default arguments provided to<br>
the parser methods of kdevplatform. It seems to have made uses search<br>
more instant (although sometimes the background parser would still<br>
kick in), at the cost of a slower initial parsing (expected) and, more<br>
concerning, a 2.1Gb memory use against 400-500Mb when regular parsing<br>
is done. So I think it might not be the best solution to my problem.<br>
:)<br>
<br>
I am trying to see how DUChains are stored on disk, as I think this<br>
might be where the key to best performance resides - store as much<br>
indexed information on disk as possible and just retrieve it instead<br>
of computing it on demand. Will probably not make it for the demo<br>
though, so any other suggestion is welcome.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>Andreas</div><div><br></div><div>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.</div>
</div>