[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-ui-dev] Changes to the Editors preference page
|
----- Original Message -----
> From: "Stefan Xenos" <sxenos@xxxxxxxxx>
> To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
> Sent: Tuesday, 15 March, 2016 3:32:43 AM
> Subject: Re: [platform-ui-dev] Changes to the Editors preference page
>
> > 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.
Have you considered trying TabFolder/TabItem? CTabFolder is kind of dirty in it's current state - custom widget, with additional rendering where e4 adds even one more renderer which uses reflection to call the swt renderer. If someone tries to merge the two renderers (move/replace the platform.ui one to SWT) at least some of the useless work will be replaced. It's always good to fix the issue at it's root.
Alexander Kurtakov
Red Hat Eclipse team
>
> - 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
