> Simply auto-closing editors because we are unable to manage performance is not a solution.
It's the best workaround we have right now.
> 4. Auto closing editors is highly distracting during a complex debig session, because the
> important context / knowledge gets lost.
I'd argue that it's only distracting if you rely on the editor dropdown for navigation. I've used the close editors automatically preference for 15 years and was never distracted by it. I admit that the editor dropdown stops being as useful when you enable this preference -- but we offer other ways to navigate editors. We have "Open Resource" that offers opening by partial filename, and we have the history stack for returning to where you've already been. Together, they cover every use-case addressed by the editor chevron.
Besides the editor chevron, are you aware of any other place in the UI where users would even be aware of the change?
Also, could you be more specific about what knowledge is lost? The navigation history is already stored explicitly.
> I think you should jave identified some "top five" performance issues - please open bugs for them.
That would only make a difference if there were only five places in the code affected. What we actually have is a problem that's almost uniformly distributed throughout the code. All editors attach preference store listeners, create widgets, attach listeners to the E4 model, and do a thousand other things that scale linearly with the number of editors. If we only fixed 5 of them, it would make no difference at all.
Mickael alluded to a better fix, above. If we could - for example - destroy and recreate the editor itself when it was hidden without destroying its tab, that would go a long way toward resolving the performance issues... but even that can only get you so far. Some of the performance bottlenecks are in the tabs themselves. For example, instantiating a CTabItem (the object that causes the chevron count to get bigger) is a linear-time operation. So creating n tabs is takes O(n^2) time -- and that's slow even if the editors themselves aren't realized.
I guess these are solvable (mainly by reducing the visual footprint when editors are destroyed and recreated), and after they're solved I'd agree with flipping the preference back. But the default value of the preferences should reflect what provides the best user experience with Eclipse as it is right now -- now with Eclipse as we'd like it to be.