Community
Participate
Working Groups
Version: 3.4.0 Build id: I20071010-1200 Same scenario as per bug 206027. For the // dummy query for waiting until the indexes are ready part of the JavaCore#initializeAfterLoad operation, the Yourkit snapshot taken gave 2 hotspots: 1 - (35%) org.eclipse.jdt.internal.core.search.PatternSearchJob.getIndexes(IProgressMonitor) 2 - (42%) org.eclipse.jdt.internal.core.search.JavaSearchScope.add(JavaProject, IPath, int, HashSet, IClasspathEntry)
These ratio were taken in trace mode and are not really significant. Using sampling mode shows following numbers: JavaCore.initializeAfterLoad(IProgressMonitor) 3,375 97 % SearchEngine.searchAllTypeNames(...) 3,125 90 % BasicSearchEngine.searchAllTypeNames(...) 3,125 90 % JobManager.performConcurrentJob(...) 3,125 90 % PatternSearchJob.ensureReadyToRun() 1,656 48 % PatternSearchJob.getIndexes(IProgressMonitor) 1,656 48 % IndexManager.getIndex(...) 1,390 40 % Index.<init> 1,156 33 % SimpleLookupTable.keyForValue(Object) 187 5 % JavaSearchParticipant.selectIndexes(...) 31 1 % IndexManager.getIndex(IPath) 15 0 % PatternSearchJob.execute(IProgressMonitor) 1,468 42 % SearchEngine.createWorkspaceScope() 171 5 % Most of the time (70%) of the PatternSearchJob.getIndexes(IPM) is spent in index file stream creation and, unfortunately, there's nothing we can do about this. Time to create the workspace scope is around 5% of the search all type names request and so, any performance improvement in this area would not be noticeable... Finally, note that the time of initializeAfterLoad is around 3.3 seconds but PDE initialization is around 1mn on this huge workspace. So, even if we did reduce JDT/Core initialization time by 2, it would be still less than 3% on whole Java Tooling Initialization time... So, close as INVALID as it looks more than a problem with the yourkit measure than a real performance issue.
Verified for 3.4M3 using I20071029-0010 build.
