Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 331882

Summary: Unnecessary calls to getProjectDescription(IProject, true) are very expensive
Product: [Tools] CDT Reporter: Marko Tomljenovic <marko.tomljenovic>
Component: cdt-coreAssignee: James Blackburn <jamesblackburn+eclipse>
Status: RESOLVED FIXED QA Contact: Doug Schaefer <cdtdoug>
Severity: major    
Priority: P3 CC: jamesblackburn+eclipse
Version: 7.0Keywords: performance
Target Milestone: 8.0   
Hardware: PC   
OS: Windows XP   
Whiteboard:

Description Marko Tomljenovic CLA 2010-12-06 01:43:12 EST 
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
Comment 1 James Blackburn CLA 2010-12-06 05:00:47 EST 
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.
Comment 2 James Blackburn CLA 2011-02-13 11:29:48 EST 
Fixed in HEAD. A writable description is not needed to determine the language.