Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [e4-dev] Fwd: Performance problems with e4

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


GIF image

GIF image


Back to the top