Community
Participate
Working Groups
Build Identifier: 7.0.1 Hello everybody, I just encountered a use case where I thought that the CDT Indexer is stuck in a deadlock. In fact it was just so slow that I thought it is a deadlock. My case: ~18 000 symbols set per external settings provider (before the indexer is executed the first time) ~6000 src files in the project Then the Indexer seems to stop at "Collecting files". Why does it seem like that: In AbstractIndexerTask.extractFiles for each file TranslationUnit.getLanguage is called. getLanguage is then calling always: CoreModel.getDefault().getProjectDescription(project, -->true<--); This means making a copy of the 18k symbols for 6000 files ==> soooo slow Wouldn't a read access to the project description be enough for determining the language? Then the cached one could be used by all files. Reproducible: Always
There are a number of places which use the suboptimal API: - getProjectDescription(IProject, true) - getProjectDescription(IProject) where they only need a read-only copy of the project description. Should do a survey of these uses and change where appropriate.
Fixed in HEAD. A writable description is not needed to determine the language.
*** cdt cvs genie on behalf of jblackburn *** Bug 331882 - Unnecessary calls to getProjectDescription(IProject, true) are very expensive [*] ACBuilder.java 1.32 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/src/org/eclipse/cdt/core/resources/ACBuilder.java?root=Tools_Project&r1=1.31&r2=1.32 [*] TranslationUnit.java 1.115 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/model/org/eclipse/cdt/internal/core/model/TranslationUnit.java?root=Tools_Project&r1=1.114&r2=1.115