Find uses/rename is being painfully slow

[Dmitry Risenberg]

2011/3/2 David Nolden <zwabel at googlemail.com>:
...
>> The bad case is when slaveMinimumFeatures() are greater than
>> minimumFeatures() - minimumFeatures() eventually get stored in the
>> duchain and the next time the second condition fails again, causing a
>> reparse. I see two ways of fixing that: either remove the second check
>> (seems inappropriate here anyway, because it is checked in
>> sourceNeeded()) or do minimumFeatures |= slaveMinimumFeatures,
>> probably except the ForceUpdate set of flags.
>
> The check does more than what you think it does. It makes sure that
> _all_ recursive imports have the required features given through
> slaveMinimumFeatures, and it also checks whether any of the recursive
> imports have a global mismatched feature-requirement attached through
> ParseJob::staticMinimumFeatures . ParseJob::staticMinimumFeatures is
> basically the way how the uses-collector tells the parse-jobs for
> which top-contexts uses are required.

I see, so it can't just be omitted. The cases when reparsing is
triggered are when a source file is parsed with Empty features and its
imports with SimplifiedDeclarationsAndContexts. Setting source file
features |= imports does prevent reparsing on next startup. An even
better way would be to update the imports without updating the source,
but I can't see how this can be achieved - importing
(PreprocessJob::sourceNeeded) is coupled with parsing process.

> There may also be some strange other problems hidden here though.

There is also a problem with revision comparing - when a file is
reopened after some edits, it has a zero revision in tracker and a
nonzero revision in duchain. Although the contents are the same, the
difference in revision causes a reparse. This could be avoided by
checking mtimes only, but someone (PovAddict?) has pointed that it
will be wrong if there are multiple changes in one second.

-- 
Dmitry Risenberg