Skip to main content

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

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





/*******************************************************************************
 * Copyright (c) 2013 __COMPANY/CONTRIBUTOR__ and others.
 * All rights reserved. This program and the accompanying materials
 * are made available under the terms of the Eclipse Public License v1.0
 * which accompanies this distribution, and is available at
 * http://www.eclipse.org/legal/epl-v10.html
 *
 * Contributors:
 *     tomschindl<__EMAIL__> - initial API and implementation
 *******************************************************************************/
package bla;

import org.eclipse.swt.SWT;
import org.eclipse.swt.custom.CTabFolder;
import org.eclipse.swt.custom.CTabItem;
import org.eclipse.swt.events.SelectionEvent;
import org.eclipse.swt.events.SelectionListener;
import org.eclipse.swt.graphics.Point;
import org.eclipse.swt.layout.FillLayout;
import org.eclipse.swt.widgets.Composite;
import org.eclipse.swt.widgets.Control;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.Layout;
import org.eclipse.swt.widgets.Shell;
import org.eclipse.swt.widgets.Text;

/**
 * @author tomschindl
 *
 */
public class TestCTabFolder {

	/**
	 * @param args
	 */
	public static void main(String[] args) {
		Display d = new Display();
		Shell s = new Shell(d);
		s.setLayout(new FillLayout());
		
		final CTabFolder f = new CTabFolder(s, SWT.BORDER);
		{
			CTabItem item = new CTabItem(f, SWT.NONE);
			item.setText("1");
			Composite c = new Composite(f, SWT.NONE);
			c.setLayout(new Layout() {
				
				protected void layout(Composite composite, boolean flushCache) {
					System.err.println("1 RECALC");
				}
				
				protected Point computeSize(Composite composite, int wHint, int hHint, boolean flushCache) {
					System.err.println("1 RECALC");
					return new Point(0, 0);
				}
			});
			item.setControl(c);
		}
		
		{
			CTabItem item = new CTabItem(f, SWT.NONE);
			item.setText("2");
			Composite c = new Composite(f, SWT.NONE);
			c.setLayout(new Layout() {
				
				protected void layout(Composite composite, boolean flushCache) {
					System.err.println("2 RECALC");
				}
				
				protected Point computeSize(Composite composite, int wHint, int hHint, boolean flushCache) {
					System.err.println("2 RECALC");
					return new Point(0, 0);
				}
			});
			item.setControl(c);
		}
		f.setSelection(0);
		f.layout(true, true);
		f.addSelectionListener(new SelectionListener() {
			
			public void widgetSelected(SelectionEvent e) {
				f.layout(true, true);
			}
			
			public void widgetDefaultSelected(SelectionEvent e) {
				// TODO Auto-generated method stub
				
			}
		});
		
		s.open();
		
		
		while( !s.isDisposed() ) {
			if(! d.readAndDispatch()) {
				d.sleep();
			}
 		}
		
		d.dispose();
	}

}

Back to the top