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

[Lars Vogel <lars.vogel@xxxxxxxxxxx>]

> What about the other changes I proposed to the preference page?

+1 to https://bugs.eclipse.org/bugs/show_bug.cgi?id=489891

On Thu, Mar 17, 2016 at 4:04 PM, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
> Yes. I suppose an info pop-up would solve the problem, too.
>

>
>   -Stefan
>
>
> On Thu, Mar 17, 2016, 6:24 AM Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
>>
>> @Stefan, can you open a bug report for the O(n^2) performance in creating
>> N tabs? This sounds definitely wrong. If you already have some tracing data
>> why this happens, please attach it to the bug (or even better upload a fix
>> for this behavior). Maybe more issues like Bug 467499, or maybe also solved
>> with this bug.
>>
>> I personally switch on auto-close of editors whenever I notice a UI delay
>> with my >99+ editors but I agree to the general discussion that setting auto
>> close as default might be distracting for the user.
>>
>> Maybe we could bring up a small info popup the first time we hit more then
>> 99 editors and inform the user about the auto-close performance advantage
>> and allow to activate the setting via this popup?
>>
>> Best regards, Lars
>>
>> Am 15.03.2016 1:32 vorm. schrieb "Stefan Xenos" <sxenos@xxxxxxxxx>:
>>>
>>> > the number of apparently open tabs can grow to hundreds with little to
>>> > no performance penalty as there are no SWT controls or listeners.
>>>
>>> Actually, some of the performance problems occur even with just tabs --
>>> for example, incrementing the number of tabs requires instantiating a
>>> CTabItem, and creating n CTabItems takes O(n^2) time. It has a low constant,
>>> but if you create enough tabs (even without realized editors), it gets very
>>> slow.
>>>
>>>   - Stefan
>>>
>>> On Mon, Mar 14, 2016 at 6:15 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
>>> wrote:
>>>>
>>>> Hi Stefan,
>>>>
>>>> (I am pleased that you are pursuing trying to solve this performance
>>>> issue! Solving this kind of bigger problem in Eclipse always seems
>>>> like an uphill battle.)
>>>>
>>>> Perhaps there is a heuristic that can be used to determined when to
>>>> close editors earlier before we worry about the "critical" number of
>>>> active editors. e.g. Only close editors that are AbstractTextEditors
>>>> with no undo buffers?
>>>>
>>>> Also, instead of closing the editor completely, how about replace it
>>>> on the editor stack with an unrestored Editor? That way all the editor
>>>> tabs are preserved, the number of apparently open tabs can grow to
>>>> hundreds with little to no performance penalty as there are no SWT
>>>> controls or listeners. This method also preserves cursor
>>>> location/selection. Specifically I am referring to functionality
>>>> org.eclipse.ui.IPersistableEditor adds to an editor.
>>>>
>>>> Doing the the two things above may allow you to free most editor
>>>> resources after only a handful (your 20 number comes to mind) of
>>>> editors are opened.
>>>>
>>>>
>>>> The other approach to dealing with the undo buffer is of course to
>>>> persist it to disk. I think that would be a good feature on its own
>>>> and if you add in autosave to the mix you get better preserved state
>>>> and a more complete restoration of your exact workbench when you close
>>>> it. Similar to local history you could have an expiration time / size
>>>> / entries. Slightly OT.
>>>>
>>>> Jonah
>>>> ~~~
>>>> Jonah Graham
>>>> Kichwa Coders Ltd.
>>>> www.kichwacoders.com
>>>>
>>>>
>>>> On 15 March 2016 at 00:25, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>>>> > Jonah, that's a pretty compelling use-case. You've convinced me that
>>>> > it's a
>>>> > place where auto-closing editors will produce a bad user experience.
>>>> >
>>>> > However, clearly we can't retain full editor states for an unlimited
>>>> > number
>>>> > of editors. At a certain point, performance degrades intolerably...
>>>> > and at a
>>>> > certain point beyond that, Eclipse crashes due to running out of SWT
>>>> > handles
>>>> > or heap space. If you reach that point you'd also lose your undo
>>>> > stack.
>>>> >
>>>> > Why don't we do some performance measurements, and pick the largest
>>>> > number
>>>> > of editors we possibly can before the performance becomes unbearably
>>>> > slow or
>>>> > anything crashes on a 32-bit VM -- and only close editors at that
>>>> > point.
>>>> >
>>>> > So we could turn on auto-close editors but make the number of editors
>>>> > as big
>>>> > at we can before performance degrades too much, and we can
>>>> > collectively
>>>> > decide what we feel to be "too much". That way you'd normally be able
>>>> > to
>>>> > keep your undo stack, but Eclipse could still resort to discarding an
>>>> > undo
>>>> > stack if it has no other alternatives but to freeze up or crash.
>>>> >
>>>> >   - Stefan
>>>> >
>>>> > On Mon, Mar 14, 2016 at 2:39 PM, Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
>>>> > wrote:
>>>> >>
>>>> >> Personally I think auto-closing editors is a bad idea. The simple
>>>> >> reason is that if you do that you dump the Undo stack of that editor.
>>>> >> That means this flow (which is pretty normal for me) would be broken:
>>>> >>
>>>> >> 1) Make an edit
>>>> >> 2) Explore around 20+ files trying to figure out exactly which method
>>>> >> did what in what call hierarchy, etc.
>>>> >> 3) Press Ctrl-Q (last edit position)
>>>> >> 4) Press Ctrl-Z because at step 2 I realized the very last thing I
>>>> >> typed in Step 1 was wrong.
>>>> >>
>>>> >> Dumping of my Undo buffer is not a good user experience.
>>>> >>
>>>> >> In addition, for graphical editors, the state is not restored well
>>>> >> when using Alt-Left / Alt-Right. i.e. you may end up back in the
>>>> >> correct editor, but not the correct scroll bar position, zoom level,
>>>> >> etc depending on the editor.
>>>> >>
>>>> >> Jonah
>>>> >> ~~~
>>>> >> Jonah Graham
>>>> >> Kichwa Coders Ltd.
>>>> >> www.kichwacoders.com
>>>> >>
>>>> >>
>>>> >> On 14 March 2016 at 20:52, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
>>>> >> >> 4. Auto closing editors is highly distracting during a complex
>>>> >> >> debig
>>>> >> >> session, because the
>>>> >> >> important context / knowledge gets lost.
>>>> >> >
>>>> >> > What is it about the behavior that is distracting and what specific
>>>> >> > knowledge is lost?
>>>> >> >
>>>> >> >
>>>> >> > On Mon, Mar 14, 2016 at 1:08 PM, Andrey Loskutov <loskutov@xxxxxx>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> See my answers inlined
>>>> >> >>
>>>> >> >> Am 14. März 2016 19:59:08 MEZ, schrieb 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.
>>>> >> >>
>>>> >> >> I'm not sure if this is the right way to solve the performance
>>>> >> >> issue.
>>>> >> >> We should identify, report and address each problem causing
>>>> >> >> performance
>>>> >> >> degradation for many opened editors case.
>>>> >> >> If you have identified some hotspots, please open bugs for them.
>>>> >> >> Simply
>>>> >> >> auto-closing editors because we are unable to manage performance
>>>> >> >> is not
>>>> >> >> a
>>>> >> >> solution.
>>>> >> >>
>>>> >> >> >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.
>>>> >> >>
>>>> >> >> This is a wrong conclusion - the users don't want that Eclipse
>>>> >> >> closes
>>>> >> >> editors automatically (I'm unaware about any editor which does
>>>> >> >> this by
>>>> >> >> default) - the users want that performance is not related to the
>>>> >> >> opened
>>>> >> >> editors count.
>>>> >> >>
>>>> >> >> BTW one possible problem with many opened editors performance
>>>> >> >> could be
>>>> >> >> that editor rulers for all editors are repainted on each
>>>> >> >> annotation
>>>> >> >> model
>>>> >> >> change (see
>>>> >> >> https://bugs.eclipse.org/bugs/show_bug.cgi?id=467499#c20).
>>>> >> >>
>>>> >> >> >> 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.
>>>> >> >>
>>>> >> >> Same as Mickael, I do not confuse the preference, I use editor
>>>> >> >> tabs
>>>> >> >> list
>>>> >> >> on the top right side of the tab area.
>>>> >> >>
>>>> >> >> >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.
>>>> >> >>
>>>> >> >> The editor tab schevron with the editor list. It is useful and
>>>> >> >> exists
>>>> >> >> exact dor tha purpose of visualisation of opened but not visible
>>>> >> >> editors.
>>>> >> >>
>>>> >> >> >2. That it would interfere with the editor navigation history.
>>>> >> >> >Response: It
>>>> >> >> >wouldn't.
>>>> >> >>
>>>> >> >> Sure it would. I use editors list to navigate between opened
>>>> >> >> editors,
>>>> >> >> and
>>>> >> >> since MRU can be switched off, my editors are always in exact same
>>>> >> >> order
>>>> >> >> I've opened them. Automatically closing the editors will break the
>>>> >> >> opening
>>>> >> >> order again and make me crazy searching for them.
>>>> >> >>
>>>> >> >> >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.
>>>> >> >> >
>>>> >> >>
>>>> >> >> You mean you confirm that *there IS* a performance problem?
>>>> >> >> No doubt, but I personally doubt that the auto-close preference is
>>>> >> >> the
>>>> >> >> way
>>>> >> >> to go.
>>>> >> >>
>>>> >> >> >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 think you should jave identified some "top five" performance
>>>> >> >> issues -
>>>> >> >> please open bugs for them.
>>>> >> >>
>>>> >> >> There is point 4. which you do not have yet on the list.
>>>> >> >>
>>>> >> >> 4. Auto closing editors is highly distracting during a complex
>>>> >> >> debig
>>>> >> >> session, because the important context / knowledge gets lost.
>>>> >> >>
>>>> >> >> IMHO auto closing the editors is one of the reasons why Mylin is
>>>> >> >> not
>>>> >> >> activated/used by default. This os one of the highly polarizing
>>>> >> >> preferences
>>>> >> >> where people either love or hate it. It happened to me ro be Mylyn
>>>> >> >> incompatible too, and in our lab I don't know anyone using it even
>>>> >> >> if
>>>> >> >> we
>>>> >> >> pre-install Mylyn because of Jira connector.
>>>> >> >>
>>>> >> >> I found really interesting Mickael's proposal to dispose inactive
>>>> >> >> hidden
>>>> >> >> editors but let them be on the opened edotor list - so that they
>>>> >> >> are
>>>> >> >> automatically restored if user clicks the tab again.
>>>> >> >> I've filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=489593
>>>> >> >>
>>>> >> >> >  - 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
>>>> >> >> >> <http://www.jboss.org/tools>
>>>> >> >> >> My blog <http://mickaelistria.wordpress.com> - My Tweets
>>>> >> >> >> <http://twitter.com/mickaelistria>
>>>> >> >> >>
>>>> >> >> >> _______________________________________________
>>>> >> >> >> 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
>>>> >> >> >>
>>>> >> >> >
>>>> >> >> >
>>>> >> >>
>>>> >> >> >
>>>> >> >> > > >------------------------------------------------------------------------
>>>> >> >> >
>>>> >> >> >_______________________________________________
>>>> >> >> >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
>>>> >> >>
>>>> >> >> --
>>>> >> >> Kind regards,
>>>> >> >> Andrey Loskutov
>>>> >> >>
>>>> >> >> http://google.com/+AndreyLoskutov
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > 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
>>>> >> _______________________________________________
>>>> >> 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
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > 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
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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



-- 
Eclipse Platform UI and e4 project co-lead
CEO vogella GmbH

Haindaalwisch 17a, 22395 Hamburg
Amtsgericht Hamburg: HRB 127058
Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
USt-IdNr.: DE284122352
Fax (040) 5247 6322, Email: lars.vogel@xxxxxxxxxxx, Web: http://www.vogella.com