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

[Mickael Istria <mistria@xxxxxxxxxx>]

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