Community
Participate
Working Groups
Eclipse caches which files exist on disk exist and their state. When working with projects that are frequently modified by tools outside eclipse, it is a pain to constantly having to do a Refresh manually in the GUI. It would be much more efficient from a users point of view to get a CPU penality instead of a caching mechanism that constantly gets in the way. Øyvind
See: Window > Preferences > Workbench > [X] Refresh Workspace Automatically I think this does what you are looking for.
>See: > > Window > Preferences > Workbench > [X] Refresh Workspace Automatically > >I think this does what you are looking for. If this option actually works, then it should be the default. Øyvind
If this option has any nasty side effects, then those would have to be addressed before this could be made the default obviously. (I'll be testing this option now to see that it actually works. I seem to remember that in some other bug-report it was claimed that it wasn't designed to work in all cases, but I haven't got the details on top of my head.) Øyvind
I believe that option only has impact on workbench startup. I don't think we have any option to periodically refresh the workspace.
John Arthorne claims that this does occur at runtime, using polling on Linux and some Win32 notification stuff on Windows.
I do not think this should be the default because it is resource intensive on Linux because it has to poll.
>I believe that option only has impact on workbench startup. I don't think >we have any option to periodically refresh the workspace. How about not caching information at all? The OS file system should do any caching efficiently enough for almost all purposes. In fact, are you sure that the Eclipse caching of file states is more efficient than the underlying operating systems routines? Or perhaps the information is cached for a reason other than performance. It shouldn't be necessary to do a Refresh before a Team->Commit. There is a scary error message at the end of a commit if the workspace is out of sync. Similarly for other operations, e.g Search->Files. Having to enable a preference option to "fix" these strange and frightening error messages is just wrong. My motivation for pursuing a solution to this problem is that I'm trying to get some engineers to use CVS, and all such error messags are waved as "proof that CVS is buggy, is just a big fat waste of time and besides why do we want version control anyway?" :-) Øyvind
>I do not think this should be the default because it is resource >intensive on Linux because it has to poll. "Correct but inefficient" is a better default than "mostly correct, but fast". Øyvind
Storing file stat information in memory is not a performance optimization. We need to be able to detect when a file has changed on disk. For example, the incremental Java builder needs to recompile Java files when their content changes on disk. An unchanged editor that is open on a file needs to update the characters on the screen when the contents change on disk. In the absence of "cached" information in memory, we could not detect when a file has changed, and the tools that care about those changes would not be able to react. I suggest marking this wontfix.
>I suggest marking this wontfix. There are significant unresolved user interface issues here. Should they remain unaddressed? It took me a couple of years to even consider the possibility of the existence of a "make annoying requesters go away option" in preferences. Eclipse has way to many options as it is. Is reduced performance the only thing that speaks against making "Refresh Workspace Automatically" the default? Surely this performance difference is only significant for large projects(i.e. more expert Eclipse users). I'm not even convinced that the option should exist at all, i.e. automatically updated should be the forced behaviour. Are there any numbers to back up the claim that this affects performance adversely in any significant measure? Øyvind
I agree that Eclipse has too many preferences and that they should be reduced. As well, if there are "strange and frightening error messages" then these should probably be improved. However, this bug is getting too complicated. Let's keep it about the preference itself, and if you think the error messages can be improved then please file a new bug about that. Since this preference and its default is decided by Platform Resources, I am reassigning this bug to them to consider.
Users with large projects are very common. We turned the preference off by default because we believed that users who frequently use external tools on the files in their workspace are probably less common. Forcing a performance hit on all users to support this uncommon usage was deemed unacceptable. Of course, we have no hard statistics on the number of users who frequently make external changes, or on the number of users who would feel the performance effects of having this preference turned on. We'll watch the vote tally on this bug to see how many people want this default changed. For contrast, see bug 74392, where the user has 75,000 resources in a single project, and it takes over eight minutes to perform a single "refresh". For such users, turning this feature on would be disastrous.
