Community
Participate
Working Groups
In Bug 291659 a change was put in to start a index rebuild as the last step in initializing the JSPIndexManager. This was done in order to fix issues with the index not being ready when the user invoked Java refactoring or searching. In my testing this changed seemed to fix this issue, but Nick has been able to reproduce cases where this still did not fix the problem. Further more an adopter product has discovered that if a user has a large workspace then it can take upwards of 20 minutes to perform this indexing and in the process is pegging the CPU and memory usage. Further more one would assume that while this maybe a one time expensive cost if the user then closes the workspace after the indexing finished and then opens it again the long running CPU pegging indexing occurs AGAIN. I believe that this initial index should be removed for the time being and a more in-depth investigation needs to take place into the JSPIndexManager and how it can be improved both in efficiency and allowing operations like Search and Refactor to be able to wait for the index to to finish building before executing (which they currently cant, as well as discover why files that have already been indexed need to be re-indexed when the workspace is re-loaded for Java search and re-factor to work. Patch to follow.
Created attachment 162865 [details] Patch to remove intial rebuildIndex call Patch as discussed in bug description.
As much as it saddens me, the performance hit is too severe to let it go live like this. We cannot rebuild the index like this at every startup. Please continue to investigate the reason the indices are not correct on workspace startup.
