OK, just took a quick glance at the editor tab switching behavior. The stack renderer issues 3 layout calls (from line 644) but two of these calls are for the Outline view as it switches content pages, there's only one call to the CTF containing the editors. It's possible we could / should optimize this one as well but I think that working on the CTF'a layout will get us the most improvement (i.e. the StackRenderer changes won't affect the sash layouts...
I'll have a talk with Bogdan...
Eric
From: Eric Moffatt/Ottawa/IBM@IBMCA
To: E4 Project developer mailing list <[email protected]>,
Date: 09/05/2013 11:16 AM
Subject: Re: [e4-dev] Fwd: Performance problems with e4
Sent by: [email protected]
Tom, thanks for the valuable input...there appear to be two parts to the
problem:
1) Multiple (possibly unnecessary) calls to layout from within the
StackRenderer.
2) A non-optimal SWT CTabFolder layout that exacerbates the layouts above
Could you open a couple of defects 1) Against Platofrm UI and 2) against
SWT (you likely want to attach the 'TestCTabFolder' class to this one) ?
Do you have any information indicating *which* of the two might be causing
the observable slowdown ? From the comments I'm guessing that fixing the
CTF issue would likely help more that fixing the renderer. Tom, have you
tried to see whether you can fix the renderer issue ? If you do could you
attach a Gerrit patch to the defect ?
I only see two calls to layout in the stack renderer, both associated with
supporting the CTF's toolbar / menu. How many calls to the CTF's layout
happen when switching editors ?
Sounds like Mission Control will be a great stress test for e4...;-), once
we've fixed these please report any other bottlenecks you encounter.
Onwards,
Eric
Inactive hide details for Tom Schindl ---09/04/2013 03:34:22 PM---Hi, Below
is the analysis of Johan from Oracle why their applTom Schindl
---09/04/2013 03:34:22 PM---Hi, Below is the analysis of Johan from Oracle
why their application is
Fro Tom Schindl <[email protected]>
m:
To: E4 Project developer mailing list <[email protected]>, Johan
Ringdahl <[email protected]>,
Dat 09/04/2013 03:34 PM
e:
Sub [e4-dev] Fwd: Performance problems with e4
jec
t:
Sen [email protected]
t
by:
Hi,
Below is the analysis of Johan from Oracle why their application is
suffering from performance problems.
Looking at the code of StackRenderer the following things look strange:
a) we are calling layout(true,true) so often?
b) does it really need to be layout(true,true)? To me it looks like all
we want to do is to position the TabFolder so we should call
layout(Control[]) not?
c) why does CTabFolder layout even invisble tabs on layout(true,true)
this does not make sense (see attached snippet)
Tom
-------- Original Message --------
Subject: Performance problems with e4
Date: Wed, 4 Sep 2013 06:08:27 -0700 (PDT)
From: Johan Ringdahl <[email protected]>
To: Tom Schindl <[email protected]>
CC: Marcus Hirt <[email protected]>
Hi Tom
When we are running Mission Control on eclipse 4.3 instead of on 3.8, we
suffer from very severe performance degradations that make the program
unusable. This degradation is visible when comparing the eclipse IDEs as
well, but it?s much much worse in Mission Control since we hold a huge
swt-widget tree in a lot of tabs. For example moving the sash between
views and switching between editors can take several seconds. I tested
the last 4.3 release, the last 4.3 maintenance build from 29 aug and the
last 4.2.2 release, and the problem occurs with all of them.
I did some debugging, and the problem seems to be caused by layout of
CTabFolder-s. All tabs, also those in the background are layout which
shouldn?t be necessary. For example when switching between editors,
org.eclipse.e4.ui.workbench.renderers.swt.StackRenderer calls
layout(true, true) on the CTabFolder (the editor stack), which then
calls updateLayout (true, true) on all its children, which includes all
editors in the stack (that wasn?t the case in 3.8). So the time it
takes to switch between editors is proportional to the number of editors
in the stack (this effect is clearly observable). Since our editors have
a lot of multi-level tab-folders, all with a lot of widgets, this single
layout(true, true) call can take about a second.
When moving the sash,
org.eclipse.e4.ui.workbench.renderers.swt.SashRenderer calls
layout(null, SWT.ALL | SWT.CHANGED | SWT.DEFER) which results in a
updateLayout (true, true) call to all open editors for the same reason,
so moving the sash is also proportionally slow to the number of editors
in the stack.
Do you know if there are any other reports on this problem or if there
is any work in progress?
Kind regards
Johan
[attachment "TestCTabFolder.java" deleted by Eric Moffatt/Ottawa/IBM]
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________
e4-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/e4-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
