>
FYI, I pretty often end up with "99+" (mostly Java) editors in my IDE, and indeed it> consumes some memory, but never to a point that prevents me from closing them
> and getting back into a good performance state.
Okay, so you've discovered the "close all editors" action and understand that you can use it to correct Eclipse slowness when you encounter it. New users haven't discovered the action yet and almost certainly haven't made the connection between the slow performance they're seeing and the number shown in their editor chevron. The defaults should be appropriate for new users.
> Am I the only lucky one to not suffer from it?
I'd guess you have been suffering from it but just didn't make the connection between your number of open editors and the UI sluggishness. I've seen the output quite clearly in my profiler, and I don't think anyone is immune.
I've received a bunch of support tickets from users reporting sluggish performance and who just had too many editors open. The "fix" is to ask them to close all editors and enable the preference. They often respond with comments like "why doesn't Eclipse just do this by default?"... and it's a legitimate complaint. Changing the default would both improve the user experience and reduce the support costs for folks who need to answer this question over and over.
> What I'd miss with editors closing up automatically is that I actually use the order of editors
> as a breadcrumb or a stack current context(s)
The preference I'm talking about has nothing to do with the history stack and the back button. The history stack is based on editor inputs and it works just as well even if you enable the "close automatically" preference and set the number of editors to 1.
It really sounds like you're confusing the "close editors automatically" preference in the editors page with the "reuse editors" preference in the search page. That one does interfere with the history stack.
So far you've raised three objections to the preference change:
1. That it would cause editors to disappear unexpectedly. Response: The editors we're talking about have already disappeared from the tabs. If you're not referring to the tabs, please state specifically which part of the UI you expected to see the editor in but could not find it.
2. That it would interfere with the editor navigation history. Response: It wouldn't.
3. That there is actually no performance problem if you have a large number of realized editors. Response: Confirmed via profiler output, end-user reports, and static analysis of the code involved.
I believe I've addressed 1 and 2 quite well. However, if you're still unconvinced about 3 I would be happy to offer some data to back up my claim. Unfortunately, I can't share my support tickets with you, but I could offer profiler output and code references to code which performs linear operations on the number of editors. What would you find most compelling?
(I'll be happy to back up my claim with data, but please don't repeatedly ask for more evidence as a stalling tactic.)
- Stefan