| Re: [platform-ui-dev] Changes to the Editors preference page |
> 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.
I don't think it's reasonable to ask that editor implementations to never attach a listener or allocate an SWT resource, so I don't think the linear slowdowns and memory usage are bugs. The bug is that we permit an unbounded number of realized editors to exist at all. That's a huge price to pay when the only user-visible consequences are:
- A bigger number in the chevron
- The editor is reachable using ctrl-e (which itself is an unnecessary binding since you can get to the files just as easily with ctrl-shift-r).
- More editors remember their selection states and cursor position.
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. For them we can keep the preference... but the default should be the one appropriate for the majority of users. I suspect that most people who don't use "close automatically" aren't even aware of the performance problems they've opted into. They just come away with the impression that Eclipse is slow and a memory hog.
Maybe some day we'll find a way to implement an unbounded number of editors efficiently. That would be awesome -- and at that point, we can flip the default to the other position... but with the way Eclipse behaves right now we shouldn't be imposing this on all new users.
> I personally do not use the "Close editors automatically" because I find this highly surprising and distracting feature
It sounds like you may not have actually tried the exact settings I suggested. At 20 editors, the ones being closed would always be hidden in the chevron. The only difference would be that the number in the chevron would stop growing after 20, but the actual tabs you see wouldn't change. Unless you rely on ctrl-e heavily, you probably won't even notice the difference. Also, if you weren't previously aware that this was the cause of performance issues, you may be pleasantly surprised with how fast everything runs when you reduce your number of realized editors.
- Stefan
Hi,> - Close editors automatically will be enabled-1 to *this* part of the proposal. The rest makes sense.I personally do not use the "Close editors automatically" because I find this highly surprising and distracting feature ("where is the editor ABC now?"), so I personally would not like to see it set by default.> There are many operations in Eclipse which slow down linearly with respect to the number of open editorsWhich concrete operations do you mean here? Bug? If we have known performance issues with many editors, we should better investigate and fix them one by one.Gesendet: Montag, 14. März 2016 um 00:44 Uhr
Von: "Stefan Xenos" <sxenos@xxxxxxxxxx>
An: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Betreff: [platform-ui-dev] Changes to the Editors preference page_______________________________________________The current defaults in the editors preference page result in an unbounded number of editors being open, which results in poor performance and memory usage after the user has viewed a large number of files. There are many operations in Eclipse which slow down linearly with respect to the number of open editors. This is a poor user experience._______________________________________________ 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-devI would like to propose that we change the defaults as follows:- Close editors automatically will be enabled- Number of editors before closing will be set to a higher constant (20).- The behavior when all editors are dirty or pinned will be "Open new editor"Raising the constant will make the change in default behavior less noticable to people who were familiar with the old behavior, and will also save the cursor position and editor state for a larger number of recent editors.Further, I propose that we remove the option to "Prompt to save and reuse" from the UI since it doesn't seem to do anything useful. It's behavior is very similar to "Open new editor" except that it also interrupts the user with modal dialogs periodically. It's unlikely that many users select this intentionally if they understand what it does, but leaving the option in the UI just increases the probability of users selecting it by accident. We can keep the preference around for RCP apps which may be relying upon it, but I don't think we should expose it in the UI.Thoughts?- Stefan
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