Re: [e4-dev] Fwd: Performance problems with e4

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

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
>