Gathering the set of files-to-watch

[Milian Wolff]

On Saturday 12 June 2010 23:33:12 Esben Mose Hansen wrote:
> On Saturday 12 June 2010 23:11:09 David Nolden wrote:
> > No you simply shouldn't care about this. The background-parser and the
> > parse-jobs will figure out the right thing to do, you should just give
> > them the lowest features that you want, which is
> > "VisibleDeclarationsAndContexts".
> 
> Alright. I don't get it, but I probably know too little about how it works
> to understand. It would certainly be easy enough to change in any case.

The only difference at all would be Uses, since the AST feature is only used 
for refactoring and the CLI tools. So using that should be fine. If the users 
wants to find uses he can request that...

> > > Still, I think the limit is about 8K directories, so there is some
> > > headroom still.
> > 
> > I hope the watches won't be a too hard hit on the performance.
> 
> Watches should only affect performance for file creation if using FAM and
> if creating a large number of files, I gather. This might be a problem
> during build. For INotify, there should be no noticable effect, as it is
> designed to handle watching the entire filesystem. But I will test this
> properly once I get it working. For the current system, with kdevelop and
> project files only, there is no visible performance degradation, though I
> have not yet done the hard numbers test.
> 
> Of course, some CPU cycles will burn during reparse. If the reparse is
> actually needed, I don't see how we can avoid it. If it turns out that we
> get a large number of useless reparses, we might be able to come up with a
> strategy to prevent it (like hashing files and checking the hash before
> reparsing).

We already have a way to prevent useless reparsing by checking 
EnvironmentFile::isUptoDate or how it was called. It only uses the timestamp 
though.

So if the user touch'es a whole folder, everything will get reparsed.

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100613/58b93cc7/attachment.sig>