Find uses/rename is being painfully slow

[floris]

On Tue, 2011-03-01 at 19:27 +0000, David Nolden wrote:
> 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
> 
gcc doesn't look at modifications at all, it's make you're referring to,
and yes that's what it does.

Floris