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 <[email protected]> > > To: > > > E4 Project developer mailing list <[email protected]>, Johan Ringdahl > <[email protected]>, > > Date: > > > 09/04/2013 03:34 PM > > Subject: > > > [e4-dev] Fwd: Performance problems with e4 > > Sent by: > > > [email protected] > > ------------------------------------------------------------------------ > > > > 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 > _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
