Find uses/rename is being painfully slow

[David Nolden]

2011/3/1 Dmitry Risenberg <dmitry.risenberg at gmail.com>:
> I've tried adding the document for parsing twice - simple parsing with
> normal priority and full parsing with low priority. This way renaming
> speeds up a lot.

I cannot see how this could speed up the renaming. Before uses can be
searched, the _full_ parsed result is required anyway.

> However, there is still a problem - some of the files are reparsed too
> often (on every startup, even if they are not changed), and this kills
> most of the gained benefits. I'm trying to debug this issue, but it is
> complicated, because there are no unit tests for background parsing
> and duchain. Looks like the call for 'featuresSatisfied' on
> preprocessjob.cpp:199 is failing, but I can't track why.
>
> So the question is - how can I debug duchain-related code and see what
> is stored in duchain - which file, with what features, when it was
> parsed, etc.? And is there any special way to debug updating-related
> issues?

We'll have to live with the fact that we need to re-parse nearly
always. For example, it's enough if you open one central header-file,
insert one character and remove it again (the revision is now
changed), now you start your rename, parse everything, and when you
re-start kdevelop you will have to re-parse everything again, because
the document revision is different.

In future, we should consider using something like "semantic
revisions", eg. special persistent revisions which we only increase
for a document when a part of its public interface has changed (a
macro, public function or public class was changed). Right now, we
basically do it the same was as gcc, which only looks at
modification-times (from what I know).

The updating stuff can be debugged, by commenting out
DEBUG_NEEDSUPDATE in modificationrevisionset.cpp. However, I debugged
this code many times, and most probably the only problem are these
document revisions.

Greetings, David