Community
Participate
Working Groups
I have a CDT project containing about 1500 files. This morning I wanted to refresh a directory where I have added some files directly in the file system. Although this directory contains only a few files, Eclipse is working since then. In the status bar, it informs me that it is - Building workspace: (0%) - Refresing workspace - C/C++ Indexer Building workspace occurs most of time and the progress is always 0%. When I try work with Eclipse, it blocks for a few seconds until I can enter a few characters in an editor or so. I quit Eclipse and restarted it again, but the same behavior starts again. How can I stop the building workspace process? I noticed already earlier that refreshing only small directories takes a lot of time, but it was never as bad as now.
You should definitely disable automatic build with a large project (Project > Build Automatically). It is the default for Eclipse and with JDT it works quite well, but it does not scale with CDT and a non-trivial project. See also bug 151770. I suppose, with auto-build off, refreshing will be faster.
I am seeing this problem too. My project is 100% Java (no C/C++). "Build Automatically" is "off" (I never use it). Project size is approximately 620 files. The Progress window/tab shows an active "Refreshing Workspace" task and pegs the CPU to 100%. The background refresh never stops; it will continue indefinitely unless I manually kill it (and sometimes it won't die, requiring a restart of Eclipse). Platform: WinXP-Pro, Eclipse Version: 3.2.1, Build id: M20060921-0945
I am seeing this on a C project with a number of 6000+ line files and probably a thousand files total. Currently, I'm running CDT as a manually launched plug-in since I wanted the code-folding patch. However I notice that Eclipse is blocking for a few seconds at a time just as described above. It only does this when I make changes in the editor, but any change can spawn this from selecting text, copy/pasting, to adding text. During this period, the processor usage goes to 100%. A copy/paste procedure can block for as long as 3-4 seconds. It may be unrelated, but it seems this obtrusive background task is also affecting the UI by disappearing my Template Proposals pop-up each time I summon it using CTRL-Space. The pop-up appears for about 2 seconds, then disappears. So I'm thinking the code that updates the editor and is doing any background builds needs to be held off any time the Template Proposal pop-up is summoned. This behavior is probably a different bug but I expect is being exposed due to this blocking issue I'm experiencing. I don't recall v3.3 of Eclipse ever behaving this way. In hopes of finding a culprit I've disabled: Build Automatically Refresh Automatically Spell Checker Auto Make Follow Unindexed header files... I can't find any other automatically performed things or timeouts I can set to prevent this bog. Ultimately, I could care less if my processor stayed pegged at 100% with background tasks as long as they don't block the editor or my project explorer. The thread(s) controlling the editor and any user interaction like summoning the Template Controls or accessing menu options should always have priority over any automatic/background task...IMO.
(In reply to comment #3) > I am seeing this on a C project with a number of 6000+ line files and probably > a thousand files total. Currently, I'm running CDT as a manually launched > plug-in since I wanted the code-folding patch. However I notice that Eclipse is > blocking for a few seconds at a time just as described above. It only does this > when I make changes in the editor, but any change can spawn this from selecting > text, copy/pasting, to adding text. During this period, the processor usage > goes to 100%. This is a different issue. The editor can get rather slow with very large files due to the reconciler updating the model in the background and the associated features, like semantic highlighting, folding, etc. Although most of the processing happens in the background, the UI update can block editing. See also bug 54040, bug 73887 and bug 163075. For large projects it may also help to increase tha Java VM heap size limit. > It may be unrelated, but it seems this obtrusive background task is also > affecting the UI by disappearing my Template Proposals pop-up each time I > summon it using CTRL-Space. The pop-up appears for about 2 seconds, then > disappears. So I'm thinking the code that updates the editor and is doing any > background builds needs to be held off any time the Template Proposal pop-up is > summoned. This behavior is probably a different bug but I expect is being > exposed due to this blocking issue I'm experiencing. I don't recall v3.3 of > Eclipse ever behaving this way. This sounds like a different problem. Could you open a new bug for that?
I think I found my problem. It was the indexer. I had it set for full indexing, not fast indexing. After setting it to fast, my Template Proposal popup no longer gets clobbered. Things seem to be faster and the UI doesn't block nearly as bad as it did before. So far, the editor is actually usable again with this indexer setting.
I spoke a little too soon. The blocking is still there, but moving the indexer to fast index helped a lot. The UI is blocking but at least blocks are only for 1/2 second or so not 2-4 seconds like it was. Until this is fixed, I can learn to live with it. BTW, I did up the memory allocation allowed by calling eclipse with the arguments: eclipse.exe -vmargs -Xmx640m So far, I'm not getting the out of memory errors I was frequently getting before, but I just made this change so a few days of working with it will determine whether this change is making a significant difference or not.
I have had this problem for a long time, regardless of the type of project (mostly JDT though). Once I read a tip that this could be caused by readonly files in an open project. And indeed, making sure that all files in open projects are writable helps. I run a cygwin chmod command several times a day and that solves the problem.
As of the latest CDT update (Build 200804020801), this has been much less of an issue. I'm able to run Full Indexing with very little blocking as compared to before. As for read only files, I'm forced to deal with read only files. The read only flag is the method my Version Control (Perforce) uses to determine if it has control of the files or if the files are under my control. In cases where I have files checked out of VC, it knows about those instances and marks those files as writable on my HD. The writable flag is recognized by Eclipse and I can make edits. When I check my changes back into VC, the files are reverted to read only again. If I force a file to writable when it is not checked out of VC, the VC will not update the file when other developers have checked in changes to that file. In some cases, this is desired behavior (i.e. environment BAT files). However forcing all files in my projects to writable isn't really an option because I need VC to give me updates as other developers are checking in changes or my workspace becomes out of date in a very short order. Point being, if there is a problem with Eclipse handing read only files, this needs to get fixed to allow Eclipse to work with VC softwares. Thus this problem, if reproducible, raises the priority of this bug higher than normal. However, I have not been able to attribute any such issue running the CDT build indicated above. Perhaps others can.
