Re: [platform-ui-dev] Changes to the Editors preference page

[Stefan Xenos <sxenos@xxxxxxxxx>]

> 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

On Mon, Mar 14, 2016 at 4:35 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:

On 03/14/2016 09:17 AM, Stefan Xenos wrote:

> If we have known performance issues with many editors, we should better investigate and fix them one by one.

I'm not sure how you would fix it. How would you keep an unbounded number of realized editors in memory without consuming an unbounded amount of memory?
You could lazily destroy editors, remember their inputs, and recreate the actual widgets the next time it's brought to foreground... but that's pretty much what "close editors automatically" does.
The performance problems are all over the place. Editors contain a ton of widgets, and most stuff in SWT gets slower with more widgets since it's filled with depth-first-searches over the widget hierarchy. Editors register lots of listeners, and sending events to listeners is linear in terms of number of listeners. Many editors also allocate SWT resources which eventually results in the SWT out of handles error. Then there's the working copies, workbench activation history, and tons of other stuff editors do that scales linearly (in runtime and memory) with the number of editors.

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. So I do not believe there is a performance problem with the simple amount of open editors growing. However, there are definitely some editors that consume a lot of resource when open and that it's better to close whenever they're not used, but I don't believe it's a problem that requires Platform's attention nor that is strong enough to introduce a new behaviour.
Also, I wouldn't like editors to close automatically by default, since some actions such as debugging often require to open a lot of files (debugging some complex things can request to open more that 20 files sometimes).

Sure, there probably ARE users that would miss the old behavior, are willing to pay the performance penalties, and don't mind restarting due to the occasional OOME.

As I mentioned above, I never face the need to restart because of an OOME caused by too many open editors. Is there a bug report on this topic? Am I the only lucky one to not suffer from it?

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), and I find it very important to keep this organization as I take very often advantage of it. I guess many developers do the same thing. Closing some editors randomly would make this usage not fully possible.

--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev