Find uses/rename is being painfully slow

Aleix Pol aleixpol at kde.org
Fri Feb 18 12:50:19 UTC 2011


On Fri, Feb 18, 2011 at 10:21 AM, David Nolden <zwabel at googlemail.com>wrote:

> For full-project parsing, we collect a reduced amount of information,
> where basically only the types of globally accessible objects are
> processed fully (for example functions), but the actual code contained
> by functions is not processed at all, and uses are not built at all.
>
> You can experiment with this using the "duchainify" command-line
> utility, and you will see that building the full duchain with uses
> etc. is something like 50 times slower then the reduced version.
>
> Basically, the "find uses" (and replace) code works like this:
> * Collect all declarations of the function we want to find uses for
> * Collect all source files that recursively include the headers
> containing these declarations
> * Build the "full" duchain for all those source files
>
> When there are many source files including the given header(s), then
> this will become painfully slow.
>
> There are two things we could do to speed this up:
> 1. Do a simple "grep" to filter out source files that can not contain
> uses of the given object (this will break with uses within macro
> invocations though)
> 2. (optional) Only build uses for contexts that contain an appearance
> of the string found by the "grep".
>
> Each of these would bring a huge improvement, but the second is pretty
> complicated to do.
>
> Greetings, David
>
> --
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>

But why is the current file reparsed when you're renaming a local variable?
The current file should have all the information already, no?

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110218/159de3d3/attachment.html>


More information about the KDevelop-devel mailing list