Community
Participate
Working Groups
Currently, the (new) indexer makes no use of change deltas when performing indexing. The indexer rescans the entire workspace to determine what changed when processing any change. This is fairly fast, but we could still make it a lot faster if we made use of the content of change deltas (since we wouldn't have to check the fingerprints of the remaining files). There are several objectives of this change. 1. Allow the indexer to run faster for incremental changes. 2. Move the responsibility for computing the set of files to scan out of the indexer thread and into the thread that requested re-indexing (in order to address bug 509558). 3. Provide a more selective blocking mechanism - such that a caller can wait for a specific file to be reindexed instead of just waiting for the entire workspace, as it does now. Item 3 may be moved to another bug if it doesn't fit. The plan is to provide the indexer with a work queue data structure containing the list of outstanding files to be rescanned, which is populated by the APIs that trigger re-indexing. The data structure would also contain some mechanism for prioritizing elements that other threads are waiting on and for enqueuing other tertiary tasks (like updating last-used timestamps and workspace mappings). The current responsibilities of the indexer will be broken up into various tasks enqueued in the work queue, the APIs that enqueue new work, and the indexer itself.
bulk move out of 4.8
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Is it really OK to close this issue? It looks like it can have a lot of impact on the performance. And looking at https://wiki.eclipse.org/JDT_Core_Index_Programmer_Guide it highlights quite a lot of limitations with the current implementation.
