Description John Arthorne 2001-10-10 22:53:47 EDT

While doing performance tracing in OptimizeIt, I noticed that the indexer thread was doing
work in situations where it seems like it shouldn't.  For example, if you do a "Team->Synchronize with Stream",
it re-indexes all java files, even though their content hasn't changed.  I traced this down to
DeltaProcessor#updateIndex, which has the following code for dealing with changed java files:

			IFile file = (IFile)delta.getResource();
			String extension;
			switch (delta.getKind()) {
				case IResourceDelta.ADDED:
				case IResourceDelta.CHANGED:
					if (file.isLocal(IResource.DEPTH_ZERO)) indexManager.add(file);
					break;
				case IResourceDelta.REMOVED:
					extension = file.getFileExtension();
					indexManager.remove(file.getFullPath().toString(), file.getProject());
					break;
			}

Under the CHANGED case, it should only be concerned with deltas with the F_CONTENT
flag set, otherwise the indexes shouldn't be affected. As it is now, it will re-index files
with sync info changes, session property changes, marker changes, etc, unnecessarily.
This is causing a lot of unnecessary work in the index thread.

NOTES:

PM (9/6/2001 3:16:59 PM)
	Agreed, we should not reindex the world unless the content has changed.

JohnA (9/6/2001 10:08:52 AM)
	There may be other opportunities to improve the java delta processor performance
	in this case.  When doing "Synchronize with Stream" on a typical java project, 20-30% 
	of the total time is taken in jdt.internal.core.DeltaProcessor.processResourceDelta.  Most of 
	that time seems to be taken in creating java elements corresponding to the changed resources.
	This could perhaps be improved in cases where the delta does not represent content changes.

PM (9/17/2001 1:26:13 PM)
	Checking the flags for reconciling with .classpath file and triggering file indexing.