Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT does not perform will with "large" projects

I'm very familiar with some of issues you wrote about (we have customers with hundred megabytes source base).Some of these problems , such as indexer performance,are out of our control, for others work arounds were found.


On 16/02/20
* The CMake generator did not properly set up the set of include
   paths. None of the GCC system include paths were added. After
   manually adding them, I had to rebuild the entire index. Just
   updating the index did not help.
This is a question to CMake-based tool chain integrator responsible for adjustment of discovery customization.

* When my CMake-project is open, Eclipse is regularly totally
   unresponsive for several seconds up to sometimes several minutes,
   with no visible cue as to what it is doing.
I believe this is indexer, but don't have any reasonable advice how to fix this.

* The indexer takes a very long time to run and is very
   memory-hungry. IMHO, if CDT is to be a competitive alternative to
   Visual Studio, the indexer performance must improve.

* Eclipse consumes>  100% CPU when I have my CMake-project open. No
   background jobs are being run, the indexer has completed, but still
   the Eclipse process is hogging all the CPU. I'd love to produce a
   bugreport, but I simply don't know what to put in it.

* I tried importing the CMake-project inside a runtime Eclipse and
   debug it. This did not work since the runtime Eclipse dies with a
   OutOfMemory error while doing some decorator work.
This is a problem with implementation of decorators update. Try before starting import to close project explorer and open C/C++Projects veiew instead, and you'll see essential improvement. The most radical solution (and it worked for me), was in CNavigatorProblemLabelDecorator.firesProblemChanged() method to set threshold to 0. However, accurate implementation of importer (temporary switching off indexer and setting maximal priority to the thread our importer running) provides now an acceptable time user waits until import finishes.



Back to the top