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
