> since I profiled it in 2005.
I'm amazed that you remembered any performance number from 2005. Great
to have you with your experience working again on Eclipse.
> At 1000 tabs, there was a noticeable delay when switching tabs (300ms or so spent in CTabFolder). That may be worth
> investigating if you'd still like me to file something...
Yes, please, if you found a bottleneck, we should definitely try to
improve that.
Best regards, Lars
On Thu, Mar 24, 2016 at 4:29 PM, Stefan Xenos <sxenos@xxxxxxxxx> wrote:
> I wrote a benchmark for it, but I must have misremembered where the
> bottleneck was (or perhaps computers got faster since I profiled it in
> 2005.) The CTabItem constructor worked reasonably fast for below 1000 tabs,
> so I didn't file a bug.
>
> Sorry for spamming the list with bad information. (Note that this doesn't
> mean Eclipse performs well with unlimited numbers of tabs - just that the
> CTabItem constructor isn't at fault)
>
> At 1000 tabs, there was a noticeable delay when switching tabs (300ms or so
> spent in CTabFolder). That may be worth investigating if you'd still like me
> to file something...
>
> - Stefan
>
>
> On Thu, Mar 24, 2016, 1:39 AM Lars Vogel <lars.vogel@xxxxxxxxxxx> wrote:
>>
>> Created for the proposal to warn the user about this.
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=490353
>>
>> Stefan, did you create a bug for the O(n^2) performance issue? Warning
>> is good, but I think we should leverage your performance measurements
>> to improve this situation in general.
>>
>> Best regards, Lars
>>
>> On Thu, Mar 24, 2016 at 12:17 AM, Stefan Xenos <sxenos@xxxxxxxxxx> wrote:
>> > Yes, that one and many others. :-(
>> >
>> > ...but if we were to open the notification that Lars suggested above, at
>> > least users would be aware of why their performance is degrading and be
>> > aware that there's something they can do about it.
>> >
>> > On Wed, Mar 23, 2016 at 2:37 PM Snjezana Peco <snjezana.peco@xxxxxxxxxx>
>> > wrote:
>> >>
>> >> The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=467499 would
>> >> need to significantly improve performance if there are many opened
>> >> editors in an Eclipse workspace (at least on Linux and Mac).
>> >>
>> >> Snjeza
>> >>
>> >> On 3/18/2016 11:00 AM, Lars Vogel wrote:
>> >> >> 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
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> 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
>> _______________________________________________
>> 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
_______________________________________________
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
