Community
Participate
Working Groups
The creating of TableColumn objects seems to be what slows things down. Every fourth column takes significantly longer than the rest. This seems to be due to the fact that SWT allocates memory for the table four columns at a time (Table.class line 683). Performance on windows is fine. The code listed below runs in < 1 sec on windows but takes approximately 200 seconds on linux on the machines I'm using. import org.eclipse.swt.*; import org.eclipse.swt.events.SelectionAdapter; import org.eclipse.swt.events.SelectionEvent; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class ManyColumnTable { Table table; int columns = 1000; int rows = 80000; public static void main (String [] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new GridLayout()); final ManyColumnTable mct = new ManyColumnTable(); mct.table = new Table (shell, SWT.VIRTUAL | SWT.MULTI | SWT.BORDER | SWT.FULL_SELECTION); mct.table.setItemCount(mct.rows); mct.table.addListener(SWT.SetData, new Listener(){ public void handleEvent(Event e) { int index = e.index; TableItem item = (TableItem) e.item; item.setText(String.valueOf(index)); } }); GridData data = new GridData(SWT.FILL, SWT.FILL, true, true); data.heightHint = 200; mct.table.setLayoutData(data); Button button = new Button(shell, SWT.NONE); button.setText("Add Columns"); button.addSelectionListener(new SelectionAdapter() { @Override public void widgetSelected(SelectionEvent e) { mct.addColumns(mct.columns); } }); shell.pack (); shell.open (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } public void addColumns(int columns) { long start_outer = System.nanoTime(); for (int i=0; i<columns; i++) { long start_inner = System.nanoTime(); TableColumn column = new TableColumn (table, SWT.NONE); column.setText (String.valueOf(i)); System.out.println(((double)System.nanoTime() - start_inner)/1000000000); } System.out.println(((double)System.nanoTime() - start_outer)/1000000000); } }
Reproducible with SWT master as of today, GTK3.24, and Fedora 29.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I think it's not fixed. Should we keep this bug opened?
Bugs that see no activity for 2 years are auto closed if the bug still exists for you with latest releases please reopen and state so.
We got the same problem after migrating our plugin to Eclipse 4.18. I tested this ManyColumnTable with Eclipse 4.18 on RHEL 7.8. rows * columns 800 * 50 <== 0.41 sec 800 * 100 <== 0.45 sec 800 * 200 <== 1.80 sec 800 * 300 <== 4.79 sec 800 * 400 <== 9.97 sec 800 * 500 <== 18.30 sec 800 *1000 <== 148.88 sec 800 * 50 <== 0.41 sec 4000 * 50 <== 0.34 sec 40000 * 50 <== 2.35 sec 80000 * 50 <== 4.89 sec However, Eclipse 4.18 takes 1.17 seconds to load 80000 rows and 1000 columns on macOS.
Can I know any plan or comments on this performance regression problem on Linux?
Hello, I will take a look at this. Will try to get back to you by the end of the week.
Hello, I have taken a look at this. This is quite big but also apparent problem. Currently, we are keeping a GtkListStore of columns for each of the cells attributes of an item. The number of cells is determined by the number of columns. This information in the GtkListStore is used to have different rendering parameters for specific cells. Here's the problem, the GtkListStore does not allow expansion of columns after initialization, so currently the GtkListStore is being recreated growing by 4 (this is the cause of the spike in time taken mentioned in the initial bug report). In addition, when we recreate the GtkListStore, we then go through all items (rows) and copy from the old GtkListStore to the new one. For the test snippet posted, this portion takes 3 seconds (for me) everytime we need to expand. In terms of complexity, each time the GtkListStore is full, recreation of the list depends on the itemCount * number of attributes per cell * time to get/set and free the memory of the old model. I will try to create a patch that will eliminate the use of this GtkListStore and store this cell information in the TableItem instead. Lastly, I believe there are other reason for the slow down, but I will tackle this one first.
Many thanks for the investigation! I'm willing to test it if any build is available later.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/179320
