[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Fwd: Performance problems with e4
|
Hi,
CTabFolder:
-----------
Ok some findings. The problem of layouting on tab switch is because the
shell is requesting a layout recalculation this leads to recalcing *ALL*
controls in the tabs once activated even if hidden.
The more complex the editor the worse the performance even on simple tab
switches. I think we can't fix that the current tab is relayouted
(although not needed all the time) but we can fix that invisible tabs
are layouted.
But the fix is not in CTabFolder but in Composite#updateLayout(). Where
we do not layout children of CTabFolder if they are hidden (we can not
generally turn of hidden layout updates!!!)
> for (int i=0; i<children.length; i++) {
> // Optimization for CTabFolders
> if( !(this instanceof CTabFolder ) || children[i].isVisible() ) {
> children [i].updateLayout (all);
> }
> }
Renderers:
----------
I modified SashRenderer to call
ctrl.getParent().layout(ctrl.getParent().getChildren()) without any
noticeable break.
I removed the layout call in StackRenderer and things still worked as
expected but I only tested the IDE where the toolbar updates trigger an
layout pass anyways so I need to check if this causes problems in e4 RCP.
What I find extremly strange in StackRenderer is we are calling
attaching a ControlListener to each child of the composite which can
lead to 2 update calls within a event-frame so we should queue this up
using a Display.asyncExec.
Fixing those problems sash dragging and activation feels much faster
than before when many editors are open.
I already filed a bug for CTabFolder
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=416650) and will file
tomorrow one for the renderers but the most important fix is the one
from SWT.
Tom
On 05.09.13 17:32, Tom Schindl wrote:
> Hi,
>
> Both of them are problematic IMHO.
>
> a) CTabFolder misbehavior => e.g. Sash moves are slow
> b) StackRenderer misbehavior => why do we need a layout the content if
> the bounds didn't change
>
> Fixing a) would help b) a bit, imaging one has sub tabfolders who do the
> same but we should also not eagerly force a relayout when the selection
> changes (BTW CTabFolder call layout itself on each Tab change!)
>
> Tom
>
>
> On 05.09.13 17:14, Eric Moffatt wrote:
>> 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
>>
>>
>> From:
>>
>>
>> Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
>>
>> To:
>>
>>
>> E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, Johan Ringdahl
>> <johan.ringdahl@xxxxxxxxxx>,
>>
>> Date:
>>
>>
>> 09/04/2013 03:34 PM
>>
>> Subject:
>>
>>
>> [e4-dev] Fwd: Performance problems with e4
>>
>> Sent by:
>>
>>
>> e4-dev-bounces@xxxxxxxxxxx
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> 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 <johan.ringdahl@xxxxxxxxxx>
>> To: Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>
>> CC: Marcus Hirt <marcus.hirt@xxxxxxxxxx>
>>
>>
>>
>> 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
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>>
>>
>>
>> _______________________________________________
>> e4-dev mailing list
>> e4-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/e4-dev
>>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
