ECLIPSE/CDT available solutions for slow, memory-intensive problems

Tonight and toss the CDT for a few hours, almost a little thought, on the personal experience summed up, said the wrong place, but also please correct me. My environment is Eclipse3.1.1, CDT 3.0.1, JDK 1.5.0.06, Linux fc4, GCC 4.0. No other environment has been tried.

The CDT has a lot of performance/memory traps,
(1) Indexer. Some of the CDT features need to be indexer (I don't know which features need it, anyway), I did the experiment, the full indexer of a project with more than 500 CPP files takes about 1 hours. After the CDT is installed, the default indexer is turned on. If you only write small programs, you can ignore it. If you want to write in, large development, it is best to turn it off. Turn off mode: Select specific item, right key->properties->c/c++ Indexer, choose No Indexer. Or a CDT plug-in installed, in the Windows->preferences->c/c++->indexer, select No Indexer.

(2) The CDT defaults to an option "Follow #include ' when parsing working copies" is selected, and when you open a source file, all files in that file include parsing it. Affect the speed. When this option is turned off, CDT development does not feel like a difference in the speed of Java development. Turn off the method:windows->preferences->c/c++-> remove "Follow ..." The item.

(3) switch off (2) of the said option may affect the smart insert, that is, the automatic prompt function. CDT (at least in my environment) Here's a huge bug, and there's always a problem with parsing the include file. If the option mentioned in (2) is selected, the resolution of many files is not complete (from the right outline there can be found), do not know how it resolves, anyway usr/include many of the header files are resolved unsuccessfully. Parsing is not a success. Once you have edited the source files for these files, once you have entered the.,, or:: haha haha, wait, at least 5 minutes will be the result, and then your memory consumption will increase by more than 100M, if you hit one of these three, again wait, Memory leaks again. Some people on Google asked me how the CDT accounted for 1G of my memory. Check (2) There is another problem with the option that generics cannot be resolved. Turning off the option in (2), you will find that the source file in outline is fully parsed. However, a memory leak still occurs, and you need to turn off the auto activation. It's no problem when you turn it off, but you can't automatically prompt/complete the member. Turn off the method:windows->preferences-> C/c++->editor->code Assist, remove the hook in the 3 boxes below the auto activation.

This performance is almost the same as JDT. The price is that you cannot use automatic prompts/complete the basic functionality of this modern IDE. However, compared with other Ides in the Linux environment, ECLIPSE/CDT is much better at interface and ease of use. For example, the humanization of the UI, code reading, code templates, and Svn/cvs integration, then I like the CDT several times.

Finally, a little sensational:

Eclipse Booksellers have one word: Eclipse reverses Java beings. In fact, more than the Java sentient beings, even immature CDT have been fascinated by many people. I used to be like this before. Net/c#, who hated C + + at the same time, because of the design of Eclipse and its usability, as well as the related culture, began to like the development of Java and C + +, can feel the poetic charm in programming.