Community
Participate
Eclipse IDE
Address platform-specific UI performance problems. There is a noticable UI performance and responsiveness difference between Eclipse running on Windows and Eclipse running on Linux GTK, Linux Motif, or QNX Photon, all on the same hardware, with Windows clearly outperforming the others. Improvements made to SWT alone have not reduced this "performance gap" enough. In order to improve Eclipse performance in the other operating environments, we need to make a concerted effort to determine the root causes (suspects include low-level thread scheduling and synchronization), and then take steps to address them. [SWT, Platform UI] [Theme: Responsive UI]
I also dont like, that GTK2-port is so awfully slow! Here are some performance problems that i could fine: Cancas is really slow, thats wy all lightweight widgets are slow ;-( The creation of widgets is slow. repainting is slow (Move a widow over the wclipse window and look how slow everything is repainted). Native GTK2 programs dont have these problems at all... Please fix it!!
The current GTK2-port looks like a really big hack around features GTK2 simply doesnt have. It would make more sence to send some features to GTK2-developers (Z-Odering, ...) and ask if they would so kind to integrate the patches into GTK. Of cource these patches should only add some features not preventing native GTK2 apps to fail.
Clemens, can you include a benchmark or describe set of steps in Eclipse that is obviously slower on GTK vs Windows on the same hardware? Include a desciption of your processor, memory, Linux/GTK and Windows version. Thanks. The real mystery is that stand alone SWT apps don't seem an order of magnitute slower on platforms other than Windows but Eclipse does. Narrowing down this part of the problem is critical. We suspect that Linux threads may be to blame but have no proof.
> Clemens, can you include a benchmark or describe set of steps in Eclipse that > is obviously slower on GTK vs Windows on the same hardware? Thanks for your response! I´m sorry I dont have banchmarks so that I can verfify my last post. But I can try to answer your questions, maybe it is be useful for you. > Include a desciption of your processor, memory, Linux/GTK and Windows version. Thanks. I´m working with SuSE Linux 8.2,P4-1,6Ghz, 256Mb-DDR-Ram, GTK-2.2.1, and W2k. My X-Server is 2D/3D accerlated and I dont have performace problems at all running GTK2/QT apps. It seems like SWT/GTK is a constant factor slower than native GTK2 apps, because it was really ugly slow with antialiased fonts and a complex theme (geramic). With this theme native apps were a *little* bit slower (repainting). Because I was not able to remove the GTK2-Theme, I compiled everything related to GTK2 on my own (pango, atk, glib, gtk..) and so used the standard theme of gtk2. Now native apps were really fast, and also eclipse was faster, but even much slower than the motif version. Speed-Difference: (native_gtk2_themed - native_gtk2) == (swt_gtk2_themed - swt_gtk2). I know this description is a little bit strange, but I dont know any other way to express my thoughts.... > The real mystery is that stand alone SWT apps don't seem an order of magnitute > slower on platforms other than Windows but Eclipse does. I cant agree with this term. I wrote a really small SWT app, with about 60 simple, native widgets in the main-window (only Texgfields and Labels). When I move a window over it, I can see how the app is repainted. Its ~ slow as SWING based apps. With Motif I cant see at all any repainting, its amazing fast compared to the GTK2 version. I also so speed differenzes when switching between a Tabfolder and pages with many widgets (like the 60 Textfields). With motif I noticed no delay. I think eclipse is the worst exaple simple because its such a big app. Heres another thing I saw: I played a little bit arround with other VMs (I used 1.4.2), because its also very impartant that my apps run with free VMs. The interesting thing is, that its doesnt depend at all on the JVM how fast widgets are drawn. I also used GIJ to ensure that I can compile my app using GCJ. GIJ is very slow, it has not JIT and was only made to allow native GCJ compilied apps to load bytecode class files. Kaffe was the fastest(?!), it needed 28ms for changing the background-color of 25 Textfields, then SUN (30) and GIJ(32). It seems that not the Java-part causes performance problems. When I move a window fast over a SWT app, my Kaffe needs only about 5% of cpu, but X needs 45%! Maybe SWT uses GTK in a way X doesnt like? It seems theres a problem with native code... With the Motif version of SWT the JVM needed nearly the same cpu-time, but X needed much less. It looks really if SWT/GTK does something whcih makes X sad ;-) Maybe eclipse is the worst speed-example because it uses a lot of custom widgets. The editor is e.g. much slower in selecting text than the Motif version. The windows version is so fast, that I cant see any speed difference from native widgets. I think fast a Canvas is really needed, imaging big commercial apps. They all do many things "leightweight"... When scrolling very fast a long text, about 50% cpu-time is used by the VM(suns 1.4.1), 20% of X. > We suspect that Linux threads may be to blame but have no proof. I dont think (althought I´m really not experienced in low-level programming) that Linux threads are the problem. Linux threads are not really very powerful and I hope that the IBM implementation NGPT will but it seemds like Ulrich Dreppers threading library will do the race althought IBMs design is much more professional! If threads would be the problems, I think the "system" would need much more time handling threads, but "system" needs only about 2-5%. And if you mean that the kernel needs to much time to switch between the threads, I think X wouldnt need as much processor-time, it would wait most time for new work. What I dont understand is, why is it slow without reaching 100% cpu-time? (Konqueror also has the same behaviour). Maybe I can patch my kernel with NGPT, but for now I´ve to learn a lot to pass this year at school, I´m 17 ;-( I hope my infos could help you a little bit, good luck! lg Clemens
This is all great information but lots to digest. Let's focus on this: >> The real mystery is that stand alone SWT apps don't seem an order >> of magnitute slower on platforms other than Windows but Eclipse does. > I cant agree with this term. > I wrote a really small SWT app, with about 60 simple, native widgets in the Can you attach your sample code? Thanks.
O.K, here it is... Theres nothing special with this code. I´m sorry that is is written so ugly, this is my 2nd SWT app.... I know there are things which could be done much better, I didnt "waste" a lot of time in tinkering how to make things better... The whole Program is only a quick hack for a friend, so I didnt spend a minute in planning a well designed app or in optimizations.... It should be compileable without any big changes, Hope it helps! PS: Before I told you that with Motif X needs less CPU-time, this is wrong. I did not test it correctly, sorry. lg Clemens import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.events.*; public class OptionPane { // NusyDhcp app; Composite parent; TabItem options; Device dev; Composite c; Text[] values = new Text[28]; Label[] points = new Label[21]; Label[] names = new Label[7]; //public OptionPane(TabFolder parent, NusyDhcp app, Display dev) public OptionPane(TabFolder parent, Display dev) { //this.app = app; this.parent = parent; this.dev = dev; createGui(); } private void createGui() { //Gray Color for not Editable Texts, dont forget to dispose!! options = new TabItem((TabFolder) parent, -1); options.setText("Einstellungen"); c = new Composite(parent, SWT.NONE); GridLayout gridLayout = new GridLayout(); gridLayout.numColumns = 1; c.setLayout(gridLayout); Group net = new Group(c, SWT.SHADOW_ETCHED_IN); GridData srfgd4 = new GridData(); srfgd4.horizontalAlignment = GridData.CENTER; srfgd4.verticalAlignment = GridData.CENTER; net.setLayoutData(srfgd4); net.setText("Netz"); GridLayout netgdl = new GridLayout(); netgdl.numColumns=1; net.setLayout(netgdl); Composite netcomp = new Composite(net, SWT.NONE); GridData netgdd = new GridData(); netgdd.horizontalAlignment = GridData.CENTER; netgdd.verticalAlignment = GridData.CENTER; netgdd.grabExcessVerticalSpace = true; netgdd.grabExcessHorizontalSpace = true; netcomp.setLayoutData(netgdd); GridData gd1 = new GridData(); gd1.horizontalAlignment = GridData.FILL; gd1.verticalAlignment = GridData.FILL; gd1.grabExcessVerticalSpace = false; gd1.grabExcessHorizontalSpace = true; net.setLayoutData(gd1); Group range = new Group(c, SWT.SHADOW_ETCHED_IN); range.setText("Bereich"); GridData srfgd5 = new GridData(); srfgd5.horizontalAlignment = GridData.CENTER; srfgd5.verticalAlignment = GridData.CENTER; range.setLayoutData(srfgd5); GridLayout rangegdl = new GridLayout(); rangegdl.numColumns=1; range.setLayout(rangegdl); Composite rangecomp = new Composite(range, SWT.NONE); GridData rangegdd = new GridData(); rangegdd.horizontalAlignment = GridData.CENTER; rangegdd.verticalAlignment = GridData.CENTER; rangegdd.grabExcessVerticalSpace = true; rangegdd.grabExcessHorizontalSpace = true; rangecomp.setLayoutData(netgdd); GridData gd2 = new GridData(); gd2.horizontalAlignment = GridData.FILL; gd2.verticalAlignment = GridData.FILL; gd2.grabExcessVerticalSpace = false; gd2.grabExcessHorizontalSpace = true; range.setLayoutData(gd2); Group srv = new Group(c, SWT.SHADOW_ETCHED_IN); srv.setText("Server-Einstellungen"); GridData srfgd2 = new GridData(); srfgd2.horizontalAlignment = GridData.CENTER; srfgd2.verticalAlignment = GridData.CENTER; srv.setLayoutData(srfgd2); GridLayout srvgdl = new GridLayout(); srvgdl.numColumns=1; srv.setLayout(srvgdl); Composite srvcomp = new Composite(srv, SWT.NONE); GridData srvgdd = new GridData(); srvgdd.horizontalAlignment = GridData.CENTER; srvgdd.verticalAlignment = GridData.CENTER; srvgdd.grabExcessVerticalSpace = true; srvgdd.grabExcessHorizontalSpace = true; srvcomp.setLayoutData(srvgdd); GridData gd3 = new GridData(); gd3.horizontalAlignment = GridData.FILL; gd3.verticalAlignment = GridData.FILL; gd3.grabExcessVerticalSpace = false; gd3.grabExcessHorizontalSpace = true; srv.setLayoutData(gd3); //Widgets fr netcompz-Gruppe: GridLayout nlay = new GridLayout(); nlay.numColumns = 8; netcomp.setLayout(nlay); names[0] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); names[0].setText("Netz:"); values[0] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[0].setLayoutData(getValueRowData()); points[0] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[0].setText("-"); values[1] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[1].setLayoutData(getValueRowData()); points[1] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[1].setText("-"); values[2] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[2].setLayoutData(getValueRowData()); points[2] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[2].setText("-"); values[3] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[3].setLayoutData(getValueRowData()); names[5] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); names[5].setText("Gateway:"); values[20] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[20].setLayoutData(getValueRowData()); points[15] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[15].setText("-"); values[21] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[21].setLayoutData(getValueRowData()); points[16] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[16].setText("-"); values[22] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[22].setLayoutData(getValueRowData()); points[17] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[17].setText("-"); values[23] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[23].setLayoutData(getValueRowData()); names[6] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); names[6].setText("SNM:"); values[24] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[24].setLayoutData(getValueRowData()); points[18] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[18].setText("-"); values[25] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[25].setLayoutData(getValueRowData()); points[19] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[19].setText("-"); values[26] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[26].setLayoutData(getValueRowData()); points[20] = new Label(netcomp, SWT.SHADOW_ETCHED_IN); points[20].setText("-"); values[27] = new Text(netcomp, SWT.SINGLE|SWT.BORDER); values[27].setLayoutData(getValueRowData()); //Widgets fr Bereich-Gruppe: GridLayout blay = new GridLayout(); blay.numColumns = 8; rangecomp.setLayout(blay); names[1] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); names[1].setText("Von:"); values[4] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[4].setLayoutData(getValueRowData()); points[3] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); points[3].setText("-"); values[5] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[5].setLayoutData(getValueRowData()); points[4] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); points[4].setText("-"); values[6] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[6].setLayoutData(getValueRowData()); points[5] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); points[5].setText("-"); values[7] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[7].setLayoutData(getValueRowData()); names[2] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); names[2].setText("Bis:"); values[8] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[8].setLayoutData(getValueRowData()); points[6] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); points[6].setText("-"); values[9] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[9].setLayoutData(getValueRowData()); points[7] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); points[7].setText("-"); values[10] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[10].setLayoutData(getValueRowData()); points[8] = new Label(rangecomp, SWT.SHADOW_ETCHED_IN); points[8].setText("-"); values[11] = new Text(rangecomp, SWT.SINGLE|SWT.BORDER); values[11].setLayoutData(getValueRowData()); //Widgets fr Server-Bereich GridLayout clay = new GridLayout(); clay.numColumns = 8; srvcomp.setLayout(clay); names[3] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); names[3].setText("DNS:"); values[12] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[12].setLayoutData(getValueRowData()); points[9] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); points[9].setText("-"); values[13] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[13].setLayoutData(getValueRowData()); points[10] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); points[10].setText("-"); values[14] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[14].setLayoutData(getValueRowData()); points[11] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); points[11].setText("-"); values[15] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[15].setLayoutData(getValueRowData()); names[4] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); names[4].setText("WINS:"); values[16] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[16].setTextLimit(3); values[16].setLayoutData(getValueRowData()); points[12] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); points[12].setText("-"); values[17] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[17].setLayoutData(getValueRowData()); points[13] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); points[13].setText("-"); values[18] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[18].setLayoutData(getValueRowData()); points[14] = new Label(srvcomp, SWT.SHADOW_ETCHED_IN); points[14].setText("-"); values[19] = new Text(srvcomp, SWT.SINGLE|SWT.BORDER); values[19].setLayoutData(getValueRowData()); for(int i=0; i<28; i++) { values[i].setTextLimit(3); } for(int i=0; i<7; i++) { GridData tmpgd = new GridData(); tmpgd.widthHint = 60; names[i].setLayoutData(tmpgd); } setEvents(); options.setControl(c); setEditable(); setValues(); } private void setEditable() { //Schlampig und langsam immer alles zu berschreiben, aber einfach ;-) setTextActive(false); Color col = new Color(dev, 204,204,204); values[3].setText("0"); values[3].setEditable(false); values[3].setBackground(col); for(int i=0; i<3; i++) { values[(8+i)].setEditable(false); values[(8+i)].setBackground(col); values[(4+i)].setEditable(false); values[(4+i)].setBackground(col); } col.dispose(); } public void setTextInactive() //Besser mit boolean lsen! { Color col = new Color(dev, 204,204,204); for(int i=0; i < values.length; i++) { values[(i)].setEditable(false); values[(i)].setBackground(col); } col.dispose(); } public void setTextActive(boolean makeedit) //Besser mit boolean lsen! { Color col = new Color(dev, 255, 255, 255); for(int i=0; i < values.length; i++) { values[(i)].setEditable(true); values[(i)].setBackground(col); } col.dispose(); if(makeedit) { setEditable(); } } private void setEvents() { for(int i=0; i<28; i++) { values[i].addModifyListener(new CheckCorInput(this)); } //Von mit Netz synchronisieren values[0].addModifyListener(new ValueDuplexer(values[4])); values[1].addModifyListener(new ValueDuplexer(values[5])); values[2].addModifyListener(new ValueDuplexer(values[6])); //Dito mit "MIT" values[0].addModifyListener(new ValueDuplexer(values[8])); values[1].addModifyListener(new ValueDuplexer(values[9])); values[2].addModifyListener(new ValueDuplexer(values[10])); } private void setValues() { ConfStuff cst = new ConfStuff((Control) parent); IpListReader ipr = new IpListReader(parent.getShell()); cst.parse("dhcpd.conf"); ipr.parse("dhcpd.iplist"); //Wins-Werte setzten String wins[] = cst.getWins(); values[16].setText(wins[0]); values[17].setText(wins[1]); values[18].setText(wins[2]); values[19].setText(wins[3]); //DNS-Werte setzteb String[] dns = cst.getDNS(); values[12].setText(dns[0]); values[13].setText(dns[1]); values[14].setText(dns[2]); values[15].setText(dns[3]); //Subnetz-Werte setzten String[] subnet = cst.getSubNet(); values[24].setText(subnet[0]); values[25].setText(subnet[1]); values[26].setText(subnet[2]); values[27].setText(subnet[3]); //Gateway setzten String[] router = cst.getRouter(); values[20].setText(router[0]); values[21].setText(router[1]); values[22].setText(router[2]); values[23].setText(router[3]); //Netz setzten String[] net = ipr.getWholeIp(); values[0].setText(net[0]); values[1].setText(net[1]); values[2].setText(net[2]); values[3].setText("0"); //Von setzten String lowest = ipr.getLowest(); values[4].setText(net[0]); values[5].setText(net[1]); values[6].setText(net[2]); values[7].setText(lowest); //Bis setzten String highest = ipr.getHighest(); values[8].setText(net[0]); values[9].setText(net[1]); values[10].setText(net[2]); values[11].setText(highest); } private GridData getValueRowData() { GridData rd = new GridData(); rd.widthHint = 35; return rd; } private String[] getCom(int start) { String[] tmp = new String[4]; for(int i=start; (i<(start+4)); i++) { // System.out.println("Text:"+values[i].getText()+" "+i); tmp[(i-start)] = values[i].getText(); } return tmp; } public String[] getWinsData() { return getCom(16); } public String[] getRouterData() { return getCom(20); } public String[] getSubnetData() { return getCom(24); } public String[] getDNSData() { return getCom(12); } public String[] getNetData() { return getCom(0); } public String getLoIp() { return values[7].getText(); } public String getHiIp() { return values[11].getText(); } }
I've done some simple benchmarks, to try to compare the speed of the different SWT implementations. I know that this isn't very scientific and a lot of other benchmarks could be performed. So if you have other interesting benchmarks or corrections to mine, please let me know and I'll try to implement them. I've tested the Motif and GTK (on SuSE Linux 8.2) and the Windows implementation. Additionally I've tested the Fox implementation (also on SuSE Linux 8.2). The Fox implementation (swtfox.sourceforge.net) from Ivan Markov is included even though it's in a "very alpha" state, because I know that the Fox Toolkit is a very high speed widget set. Maybe this implementation are missing some features but it's looking very promising. The benchmarks are done on a 233 MHz P2, dual booting SuSE Linux 8.2 or Windows 98, 512 Mb ram, NVidia Vanta and JDK1.4.1_03. The GTK edition are measured with and without anti aliasing. I think the benchmarks shows some interesting things, (especially why GTK is feeling slow), but judge for yourself: Motif GTK GTK Fox Windows AA not AA ------ ------ ------ ------ ------ gc.setLineWidth 1254 3721 4380 1589 11480 gc.getLineWidth 17704 27644 27473 623 10050 gc.drawLine 35454 31482 31199 32578 15600 gc.drawText 18854 117403 64994 2415 13290 gc.drawText 2 23772 118667 65188 2285 13180 gc.stringExtent 55718 651667 466598 16252 18070 gc.textExtent 132206 650287 466764 16472 103420 gc.drawOval 9385 3509 3337 3515 14400 gc.fillGradientRectangle 29934 26836 26271 58568 14830 gc.drawImage 37156 6516 6469 4174 8730 canvas.getSize 34351 2033 2026 2072 4290 canvas.setSize 495 175 144 47 8840 canvas.getClientArea 26648 1982 1932 1914 4170 canvas.getBounds 45306 3191 3135 3301 10110 canvas.computeSize 49360 82627 81283 5160 25380 canvas.computeTrim 23998 73477 73370 2257 19990 The code: import org.eclipse.swt.SWT; import org.eclipse.swt.graphics.Color; import org.eclipse.swt.graphics.GC; import org.eclipse.swt.graphics.Image; import org.eclipse.swt.graphics.Point; import org.eclipse.swt.graphics.Rectangle; import org.eclipse.swt.layout.FillLayout; import org.eclipse.swt.widgets.Canvas; import org.eclipse.swt.widgets.Display; import org.eclipse.swt.widgets.Shell; public class Benchmark { public static void main (String [] args) { int i, j; long start, stop; Point p; Rectangle r; Display display = new Display (); Shell shell = new Shell (display); FillLayout fillLayout = new FillLayout (); shell.setLayout (fillLayout); Canvas canvas = new Canvas (shell, SWT.BORDER); shell.pack (); shell.open (); GC gc = new GC (canvas); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) gc.setLineWidth(1); stop = System.currentTimeMillis(); System.out.println ("gc.setLineWidth " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) j = gc.getLineWidth(); stop = System.currentTimeMillis(); System.out.println ("gc.getLineWidth " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); j = 0; for ( i = 0; i < 1000000; i++ ) { gc.drawLine ( 0, j, 100, 100 - j ); if ( ++j > 100 ) j = 0; } stop = System.currentTimeMillis(); System.out.println ("gc.drawLine " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); j = 0; for ( i = 0; i < 100000; i++ ) { gc.drawText ( "SWT is fast abc", j, j ); if ( ++j > 100 ) j = 0; } stop = System.currentTimeMillis(); System.out.println ("gc.drawText " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); j = 0; for ( i = 0; i < 100000; i++ ) { gc.drawText ( "SWT is fast זרו", j, j ); if ( ++j > 100 ) j = 0; } stop = System.currentTimeMillis(); System.out.println ("gc.drawText 2 " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) p = gc.stringExtent ( "SWT is fast" ); stop = System.currentTimeMillis(); System.out.println ("gc.stringExtent " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) p = gc.textExtent ( "SWT is fast" ); stop = System.currentTimeMillis(); System.out.println ("gc.textExtent " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); j = 0; for ( i = 0; i < 100000; i++ ) { gc.drawOval ( j, j, 100, 100 ); if ( ++j > 100 ) j = 0; } stop = System.currentTimeMillis(); System.out.println ("gc.drawOval " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); j = 0; for ( i = 0; i < 10000; i++ ) { gc.fillGradientRectangle (j,j,100,20,false); if ( ++j > 100 ) j = 0; } stop = System.currentTimeMillis(); System.out.println ("gc.fillGradientRectangle " + (stop-start)); //---------------------------------------------------- Image image = new Image (display, 20, 20); Color color = display.getSystemColor (SWT.COLOR_RED); GC gc1 = new GC (image); gc1.setBackground (color); gc1.fillRectangle (image.getBounds ()); gc1.dispose (); color.dispose (); start = System.currentTimeMillis(); j = 0; for ( i = 0; i < 100000; i++ ) { gc.drawImage(image,j,j); if ( ++j > 100 ) j = 0; } stop = System.currentTimeMillis(); System.out.println ("gc.drawImage " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) p = canvas.getSize(); stop = System.currentTimeMillis(); System.out.println ("canvas.getSize " + (stop-start)); //---------------------------------------------------- p = new Point ( 200, 200 ); start = System.currentTimeMillis(); for ( i = 0; i < 10000; i++ ) canvas.setSize (p); stop = System.currentTimeMillis(); System.out.println ("canvas.setSize " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) r = canvas.getClientArea(); stop = System.currentTimeMillis(); System.out.println ("canvas.getClientArea " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) r = canvas.getBounds(); stop = System.currentTimeMillis(); System.out.println ("canvas.getBounds " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) p = canvas.computeSize(SWT.DEFAULT,SWT.DEFAULT); stop = System.currentTimeMillis(); System.out.println ("canvas.computeSize " + (stop-start)); //---------------------------------------------------- start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) r = canvas.computeTrim(20,20,20,20); stop = System.currentTimeMillis(); System.out.println ("canvas.computeTrim " + (stop-start)); gc.dispose (); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } }
I vote for a fast GTK2 port! Currently I´m using Windows when developing with Eclipse, because SWT/GTK2 is really nerving. If High-Performance isnt possible with GTK2 at all, why dont you switch2 swtfox? There is already a more-or-less working port and it seems to be extremly fast! Also, Fox is very small and could be linked to swt statically. (BUT: I dont like the L&F of Fox and I also would like to see a faster GTK2 port, instead of a fox version)... Would it also possible that you polish your APIs a little bit. In my oppiniion the swt-api is a little bit unclean... Have a look to wxwindows how clean there api is! (Although there language is terrible ;-) ) lg Gasthäubner
If GTK2 is a problem because of design reasons, I dont understand why the fox-port will become the main toolkit for Unix. Creating a QT3 Port would be even better, I think a commercial QT3-License should be no problem for IBM, and I also think that Trolltech would agree to a special license for SWT... lg Theo
just because you are discussing SWT-performance - might be a bit off-topic. I'm just creating a technical application with a lot of graphics (curves which are beeing redrawn every 50-100ms,...) with SWT. The speed is quite impressive, but my app still eats a lot of CPU-Performance. I'm not sure if this is a SWT-Problem (JNI-Overhead?) or due to the operating-systems gui-performance . (Win32 and LinuxGTK2 are performing similar but GCJ is slower than JDK 1.4) For instance i realized, that drawing a curve with drawPolyline() is a lot faster than drawing the curve segments with drawLine(). It appeared to me, that the number of drawXXX() calls was the key to the performance of my program - what i was drawing was irrelevant. It would be nice to see more sophisticated GC-drawing methods which allow to do 'more' with fewer drawXXX() method calls. For instance draw 'maps' of lines and points with one method-call. + Besides: What i am really missing is drawing vertical text and rotating/shifting areas of an Image. thanks, a.
(In reply to Theodore Linkoln) Theodore, the issue with SWT and Qt has been reiterated over and over in the newsgroup. If you perform a search you'll see that this topic frequently appears, and each time goes into the void. If IBM buys a commercial license for Qt, they may eventually use SWT/Qt in their commercial WSAD Workbench which builds upon Eclipse, but I doubt this is possible for Eclipse. Suffice to say SWT/Fox started back in 2002 as SWT/Qt port, but I switched to Fox once it became clear that SWT/Qt will be illegal for the foreseeable future. Trolltech are not so keen on the idea of using Qt for free in a commercial Java application. For example they asked Richard Dale (the maintainer of the official Qt/KDE Java bindings) to switch their license from LGPL back to GPL, or so he told me during our mail exchange concerning the feasibility of using his bindings to build a SWT/Qt port.
I´ve heard that performance-problems are layout dependent. Hmm, maybe it would make sence to redesign SWT3.0 to make it work better on all platforms (OSX is also slow). I also would prefer a GTK2 version of SWT but it works so slow for now, that I would use FOX if it would work on my machine. If its not possible to speed up the GTK port significantly (and I dont mean 10-40%!) it would make more sence in my opinion to not continue this port and enhance the swtfox port. But, it would make sence to link swtfox statically against fox, because many linux-users dont know about fox. lg Hans Georg Bernhard
I think GTK2 would be better to be used as underlaying toolit, because its skinnable. However, GTK2 is hard to install and needs a lot of shared libraries, so maybe a statically linked fox would be a much better idea. I read the benchmark results and I was really very impressed. After all I tried swtfox and althought it looks different to gtk or qt I like it much more than this slow gtk2 port. go for fox!
It would be a good idea to create an official swtfox-version (static linked!) of eclipse, and also continue gtk2-swt. This would let the users choice between an extremly slow but nice looking version of eclipse and one that looks a little bit ugly but is really fast and useable. (The Motif version is so ugly that it isnt useable...) I´m a developer which isnt interrested in waiting for the ide, thats a reason why I switched from jbuilder8 to eclipse. I hope this will be done before 2005 and eclipse 5.6 :-) I also can only say: Go for fox! (Like Henry Goul did in his last message) mfg Luke Wurdinger
I think fox is worth to make official supported toolkit and it isn't so ugly as somebody said, on the contrary it looks like very accurate. However it's not so fast as Windows swt. In particular it has very slow scrolling and slow mouse wheel behavior. Its not work with cyrillyc charset :-( And finally it still very buggy and sometime crash. Hope this will be fixed in future.
Before "switching to" fox and "abandoning" gtk2, as some seem to be suggesting, it would be nice to find out *why* the gtk2 SWT port is slow. If it turns out that the native code of gtk2, as opposed to the SWT or Eclipse code, is at fault, why not consider helping the gtk2 developers with optimizing it. Don't let SWT become another victim of open source syndrome (instead of working together, let's do it from scratch!) Who knows, maybe when fox reaches the stability and feature richness level of gtk2, it will become just as slow.
Hi there! Of course, making GTK2 better would be the best thing. But I dont know how happy the gtk-developers would be to include code that helps swt. As far as I know there are problems with the way gtk2 calculates left space. I also believe, that the fox version would be very interresting, especally because gtk2 has become a really complex systeme, which is hard to install and to configure. lg Clemens
I've always thought that pango is to blame for GTK's slow behavior, so when I read that there was done some performance optimization in the newer versions of pango, I downloaded the newest and performed the same benchmarks as earlier. And the new anti-aliased version IS definitely faster than the old. It's even noticeable when using eclipse, but unfortunately still much slower than Motif, Fox and Windows. For some unknown reason the non anti-aliased version hasn't improved. pango 1.2.1 pango 1.2.5 ------------ --------------- Motif GTK GTK GTK GTK Fox Windows AA not AA AA not AA ----- ------ ------ ------ ------ ------ ------ gc.setLineWidth 1254 3721 4380 3695 3682 1589 11480 gc.getLineWidth 17704 27644 27473 28162 27941 623 10050 gc.drawLine 35454 31482 31199 28826 28843 32578 15600 gc.drawText 18854 117403 64994 80481 60995 2415 13290 gc.drawText 2 23772 118667 65188 81844 61091 2285 13180 gc.stringExtent 55718 651667 466598 337582 456776 16252 18070 gc.textExtent 132206 650287 466764 342217 458026 16472 103420 gc.drawOval 9385 3509 3337 1713 2987 3515 14400 gc.fillGradientRectangle 29934 26836 26271 27243 25536 58568 14830 gc.drawImage 37156 6516 6469 3500 3954 4174 8730 canvas.getSize 34351 2033 2026 2097 1938 2072 4290 canvas.setSize 495 175 144 136 126 47 8840 canvas.getClientArea 26648 1982 1932 2006 1896 1914 4170 canvas.getBounds 45306 3191 3135 3311 3105 3301 10110 canvas.computeSize 49360 82627 81283 82424 80452 5160 25380 canvas.computeTrim 23998 73477 73370 74749 73597 2257 19990
Btw.: Does SWT need a thread-safe version of GTK?
I tested SWT/GTK on 2 different SuSE Linux boxes. 1. AMD 2000 with ProSavage KM 133 card 2. AMD 2400 With NVidia GeForce4 MX 440 The second machine was about 25% faster. The same test on a machine with AMD 1000 and builtin vidia controller was really fast. As I do not have performance issue s with any other program on Linux there must be something in the SWT/GTK port. Actually all programs are more responsive on Linux than on Windows with the exception of Eclipse using SWT/GTK. To make it even more strange: all Swing applications on my box are several times faster and more responsive than SWT/GTK. So lets forget about the SWT port and go back to Swing !
John, SWT is not Eclipse. Can you comment on the performance of a stand alone SWT example to other native GTK applications? Thanks.
Steve, >John, SWT is not Eclipse. I know that SWT is a widget toolkit of Eclipse for the native OS. Purpose: - Get Look and Feel of native OS - Get speed of native OS > Can you comment on the performance of a stand alone SWT example to other native GTK applications? Thanks. I do not understand what you mean by this comment. SWT is not a stand alone program, but running as part of Eclipse. Now let us look at the status quo. SWT on Windows : looks good and is fast. Seal of approval. SWT/GTK on Linux: - too slow, although version 3.0M3 feels faster - fonts too fat for my taste SWT/Motif: faster than GTK, but fonts and widgets too ugly too be a viable option SWT/Fox: in alpha stage, fast enough, looks better than GTK. Swing: stable, fast enough, with the right LAF plugin like Plastic looks good, platform independent without the need of additional SWT libraies Even if the performance issues with SWT/GTK are solved it does not look asd good as the Windows equivalent, and is simply not good enough. Just have a look at Opera running under Windows, looks good, fonts good and is fast. I simply cannot understand that with all the emphasis of IBM on Linux it is exactly the Linux version of Eclipse which is by the poorest version. Based on these facts, I would prefer Swing or a SWT/QT port.
> I do not understand what you mean by this comment. > SWT is not a stand alone program, but running as part of Eclipse. You can run SWT without Eclipse - it is just a GUI Toolkit. Take a look at the SWT project page on eclipse.org for how to do it and try out some of the example apps that you can download from eclipse.org that are stand alone. There are too many variables within Eclipse to point at SWT as the root cause of your problems. If there is an issue with SWT you should be able to demonstrate it outside of Eclipse. Plus it gives a test case that can be used by the developers to fix the problem.
John, we just don't debate the merits of Swing vs SWT. It's not productive as they have different design points. Back to the real problem: Like Chris says, we are very interested in test cases, just like some of the benchmark code and results that are already in this problem report. Thanks.
Steve, I have not been able to track down swtexamples.jar on the Eclipse web site. There is some snippets code which I cannot get working with the instructions available, neither from the command line nor in the IDE. I work with Eclipse 3.0M3 If you point me in the right direction I can do some tests.
Created attachment 6320 [details] Gtk/C version of optionPane Clemens, I can't agree with you when you say that eclipse-gtk is the only gtk app that is slow to repaint. It looks worse on Eclipse because Eclipse is much bigger than the average gtk app. I got you example (OptionPane) and rewrote it using GTK only. Run both, the SWT/GTK and the Pure GTK side by side and compare the paint speed on both. You'll see it is the same. To compile and run the c code: bash$ gcc -o optionPane optionPane.c `pkg-config --libs --cflags gtk+-2.0` bash$./optionPane
On my machine (gtk2.2 compiled WITH (slower) thread support, kernel 2.4.22 and Xfree-4.3) the native version is much faster than the SWT version. When moving another window over the native-window I can see only very little repainting. Its really fast compared with gtk-swt, however compared to QT or GTK-1.2 its a shame for GTK2 to even repaint visible with such small guis. The SWT version needs sometimes a half cm to fully repaint when moving the window fast over it. However thanks a lot for rewriting it, thats really cool! Strange thing..... lg Clemens
Clemens, I tried to compile your little program but couldn't because of unresolved symbols: CheckCorInput ValueDuplexer ConfStuff IpListReader Could you please make a test case that doesn't depend on anything not available.
Created attachment 6336 [details] SWT/Java Version of OptionPane Steen, here is 'version' of Clemens code, you can use it.
Clemens, your result is interesting, before attaching the C code here I've tested in three different machines and, regarding with the paint, the Java code and C code had the same performance. The slower test machine I've used is a P3-500Hz, 500Mb memory. That test case you sent has not main method, so I wonder if you are running it has part of a large app when testing. Could test if modified version of your code that I just attached ? When I test this kind of scenario I run both app (the C and the Java) and I minimized all other windows (it will stop X from painting them). Did somebody else compare the Gtl/C version vs SWT/Java version ?
Hi again! > Clemens, your result is interesting, before attaching the C code here I've > tested in three different machines and, regarding with the paint, the Java code > and C code had the same performance. > The slower test machine I've used is a P3-500Hz, 500Mb memory. I tested it on two machines: A P4-1.6 and a Athlon-800, the P4 had a self-compiled GTK2.2, the Athlon-800 the gtk package that comes with SuSE-8.2. Both machines have HW-2D-accerlation. The slowdown when using swt is really huge! When moving another window over the gtk/c-version of the program, the only thing I can see, is about ~2mm repainted aray and it doesnt cause the window which is moved over it to block moving (it doesnt move really fluently with swt). The swt-version needs sometimes the half window for one repaint! I´ve tested it with Kernel-2.4,2.6, Kaffe, Java-1.4.2, GCJ(!) - always the same result... lg Clemens
Felipe, please code up a "PI only" version of the Gtk/C version of OptionPane for comparison with the C version. Thanks. Clemens, we are just not seeing the same thing you are seeing. You will need to hack OptionPane to programatically show something that is visually slower, perhaps a resize or move operation. Don't bother trying to get numbers, just get the scenario. The important thing is that we need to agree on the slowness you are seeing. That way we'll have something concrete to fix. Thanks!
Hi again! Of course I´m interrested to help you! (What does PI-only version mean)? O.K., I´ll play a little bit with optionpane, maybe I can figure out why its so slow.. lg Clemens
PI is the term we use for Platform Interface. This refers to the platform specific classes that are in org.eclipse.internal.win32 on Windows, org.eclipse.internal.gtk on GTK etc. These classes are (as close as possible) a one to one mapping of the equivalent C operating system API to Java classes and method. The point is that code that uses these classes should have the same performance characteristics and behavior as the equivalent C code. The PI is used to implement SWT on each platform, is non-portable, unsupported and subject to changes without notice. Basically, it's the implementation classes for SWT.
Is there any news about improvements in SWT-GTK2 performance? I install the 3.0-M5. I can't feel any good changes. SWT works slow as in earler versions. There are some obvious performance problems: -Bad response time for menu (like in Swing). I think GTK has this problem itself and swt just multiply it. -Strange behavior when filling the Table: immediately appears the first row then Table hangs for a while and then appears rest of the rows. This effect is absent on Windows SWT for same application. -Eclipe editor scroll the text like old Swing applications on Linux (pre 1.4 JDK). -May be the most problem is layouting? When the createContent() is working. After creation of the window it works more or less fine. -new Browser based on Mozilla has very long startup time. May be it should be replaced (or has the alternative) of the more lightweight html-rendering engine even with less functionality? I try the Fox-based SWT. It has significant advantage. As GTK-SWT it has some problems with quality of scrolling but the rest really comparable to SWT/Windows. Unfortunately swtfox -still unstable -has some issues with i18n -is not officialy supported by Eclipse project -has unusual right-click behavior -don't work with Eclipse 3.0
With the exception of the Browser, these look like problems in the Eclipse UI (over which we have no control). In particular, menu slowness can often be traced to applications running lots of code in SWT.Show for Menus. When you compare performance against Windows (or Fox), you need to be sure you are running exactly the same hardware (either 2 of the same machines or rebooting). Numbers help as well. If you wanted to look into the menu slowness for example, you could try hacking Display.runPopups() and printing times for each plaform. In order to get real numbers, you might need to call Display.update() before showing a menu and getting the start time and just before getting the end time to ensure that the time to draw the menus is accounted for on both platforms. All this from the top of my head so I could be wrong in the details. If I wasn't off doing 1,000,000 other things (including yet another round of "key bindings"), I'd be doing this myself.
I have filed a bug in GNOME bugzilla against Pango based on the benchmark data submitted here: http://bugzilla.gnome.org/show_bug.cgi?id=129473
To Steve Northover: >With the exception of the Browser, these look like problems in the Eclipse UI (over which we have no control). SWT initialy writen for Eclipse. Right?... >In particular, menu slowness can often be traced to applications running lots of code in SWT.Show for Menus. Yes. And on all platforms it should have almost equal slowness? >When you compare performance against Windows (or Fox), you need to be sure you are running exactly the same hardware (either 2 of the same machines or rebooting). Of cource. I use same computer and to compare Fox and GTK even same linux. >Numbers help as well. If you wanted to look into the menu slowness for example, you could try hacking Display.runPopups() and printing times for each plaform. In order to get real numbers, you might need to call Display.update() before showing a menu and getting the start time and just before getting the end time to ensure that the time to draw the menus is accounted for on both platforms. All this from the top of my head so I could be wrong in the details. Ok. I will try to do something with numbers. I will try all tests posted to this bug-report. Is there anybody who already has tests about menu and layouts? Anyway if you write the SWT-GTK you can better know where is (or can be) the bottleneck. >If I wasn't off doing 1,000,000 other things (including yet another round of "key bindings"), I'd be doing this myself. "key bindings"? Hmm... very helpful thing when popup-menu very slow ;-)
Thanks for running the tests. In particular, I am interested in the results of the C code versus the SWT/Java code. We couldn't see the problem that Clemens is talking about. >>In particular, menu slowness can often be >>traced to applications running lots of code in SWT.Show for Menus. > >Yes. And on all platforms it should have almost equal slowness? Not necessarily. The JDK class libraries themselves are different between Windows and Linux, specifically the natives that do file i/o and networking. Also, the thread model is different. There are lots of other variables besides SWT. >>If I wasn't off doing 1,000,000 other things (including yet another >>round of "key bindings"), I'd be doing this myself. >"key bindings"? Hmm... very helpful thing when popup-menu very slow ;-) Popup menus are fast in stand alone SWT examples.
I just tried the test provided by Clemens - C and SWT versions - and I can see no difference between the two. Dragging an xterm window over both OptionPanes feels equally slow (i.e. the motion is not quite smooth). However no visual repaint artifacts occur in either version. This is on a 1.6 GHz Athlon machine with a GeForce MX video card.
Thanks, this confirms the theory that the "slow redraw" problem is in GTK. It seems to me that GTK is double buffering and drawing in the idle handler ( a strategy used by many other X apps) in order to avoid "too many redraws" when X gives the damage for every little rectangle. There is nothing we can do about this.
Quite aside from the performance issues (it's slow-but-acceptable on my machine) I find Eclipse/GTK rather unstable. 2.1 was mostly ok but locked up or crashed from time to time; 3.0 is unusable, requiring a dual-boot to WinME in order to use Eclipse.
Are you running one of GTK 2.0.6 or GTK 2.2.1?
Alexander: Can you open a separate PR (Platform, SWT, Linux-GTK) related to the long Mozilla Browser startup time you reported in comment 35. Please provide some details there. Thanks!
>Quite aside from the performance issues (it's slow-but-acceptable on my >machine) I find >Eclipse/GTK rather unstable. 2.1 was mostly ok but locked up or crashed from >time to time; >3.0 is unusable, requiring a dual-boot to WinME in order to use Eclipse. I am using Eclipse 3.0 M3, M4 SWT/GTK for several months day in day out and have not experienced a single crash. Eclipse is as exeptionally stable on my PC. My configuration is SuSE Linux 8.2 The menus are at times a bit slow, but not to the point that Eclipse becomes unusable. User% CPU in java jumps to 25% when cliking on a menu and then hover over the other menus in Eclipse. This seems tick high to me. I repeated the same test with Opera and to my surprise the menus were not faster as Eclipse. The same test repeated with several Swing applications like SquirelSQL, DB Visualizer and Poseidon show they are just as fast as any native application on Windows or Linux. Anybody who claims Swing is slow should have a look on my machine.
Glad that Eclipse is working "ok" for you on GTK. See comment 21 for discussions about Swing. Swing being fast or slow was not relevant then and is not relevant now. Everyone else on this PR (all 30 billion of you), if you want Eclipse to get faster, you are going to have to enter performance PR's against Eclipse (with specific examples in the UI, stating the machine and memory). Let them know you are unhappy and be specific. Alternately, find SWT examples that demonstrate slowness and we will fix it. A good example of this kind of interaction is 36226. Thanks.
Steve, I'm using whatever version of GTK Mandrake 9.1 comes with. According to http://www.mandrakelinux.com/en/9.1/features/15.php3 , I think it's 2.2.1 .
Created attachment 7199 [details] Browser startup perf test
I write the test for startup performance (see attachment) of the Browser in standalone application. There are results: Browser First time Linux/Moz Windows/IE6 Browser create time: 896 731 Setting url time: 36 962 Total start time: 932 1693 Second time Browser create time: 10 80 Setting url time: 12 221 Total start time: 22 301 Third time: Browser create time: 14 80 Setting url time: 15 221 Total start time: 29 301 So, I think no need open new PR about Browser. There are another problem in my application. In Linux Browser itself works even better then in Windows. Sorry for the wrong information. About menu: I try OpenOffice and Mozilla on Windows and see same problems with menubar. In standalone swt-application menu as fast as rest of native GTK applikation I use. So this is the GTK problem + time to dinamicaly generate the menu in Eclipse. However this fact don't relief my torment with Linux Eclipse. I will continue my tests. This is result of the test from comment #7 Linux gc.setLineWidth 2013 gc.getLineWidth 4783 gc.drawLine 15648 gc.drawText 22625 gc.drawText 2 23417 gc.stringExtent 303 gc.textExtent 292 gc.drawOval 1140 gc.fillGradientRectangle 16008 gc.drawImage 2476 canvas.getSize 559 canvas.setSize 62 canvas.getClientArea 544 canvas.getBounds 946 canvas.computeSize 2982 canvas.computeTrim 1759 Windows gc.setLineWidth 2393 gc.getLineWidth 2283 gc.drawLine 10796 gc.drawText 6609 gc.drawText 2 5859 gc.stringExtent 2704 gc.textExtent 16684 gc.drawOval 3134 gc.fillGradientRectangle 1923 gc.drawImage 3745 canvas.getSize 1512 canvas.setSize 11177 canvas.getClientArea 1552 canvas.getBounds 2684 canvas.computeSize 4156 canvas.computeTrim 3204 I can't see the clue in this results. I will continue the tests. Next test is the layouts.
Response to #50: The problem are in the drawText and stringExtent/textExtent routines. The are way too slow in GTK. Note there was been some optimizations: When the same string is send to these routines no recalculation are taking place. This is the reason why the textExtent and stringExtent suddenly are so much better. The benchmark should changed to something like: start = System.currentTimeMillis(); j = 0; for ( i = 0; i < 100000; i++ ) { gc.drawText ( "SWT is fast abc", j, j ); gc.drawText ( "This is another string", j, j ); if ( ++j > 100 ) j = 0; } stop = System.currentTimeMillis(); System.out.println ("gc.drawText " + (stop-start)); start = System.currentTimeMillis(); for ( i = 0; i < 1000000; i++ ) { p = gc.stringExtent ( "SWT is fast" ); p = gc.stringExtent ( "This is another string" ); } stop = System.currentTimeMillis(); System.out.println ("gc.stringExtent " + (stop-start));
To #51 Really difference is very impressive: Linux gc.drawText 121100 gc.stringExtent 437166 Windows gc.drawText 12719 gc.stringExtent 5938
I repeaed the benchmark test of ------- Additional Comment #7 From Steen Jansdal 2003-06-25 05:17 ------- My results show a significantly faster time for drawText() and stringExtent() These methods are relatively about 10 times faster. The benchmark has been done using an Ant script in a separate JVM. My configuration is: SuSE Linux 8.2 AMD 2000+ processor 512 RAM Builtin video ProSavage KM 133 Not sure if this is relevant: Windows TrueType fonts installed Benchmark: [java] gc.setLineWidth 1181 [java] gc.getLineWidth 6126 [java] gc.drawLine 999 [java] gc.drawText 8737 [java] gc.drawText 2 8649 [java] gc.stringExtent 7367 [java] gc.textExtent 7513 [java] gc.drawOval 192 [java] gc.fillGradientRectangle 6762 [java] gc.drawImage 666 [java] canvas.getSize 614 [java] canvas.setSize 19 [java] canvas.getClientArea 476 [java] canvas.getBounds 949 [java] canvas.computeSize 2567 [java] canvas.computeTrim 1801 [java] Benchmark ready: disposing of gc
John, this is what's to be expected, since your computer is 10 times faster than mine. You can't compare results from two very different machines. Try to run the test under motif and GTK and perhaps Fox, and if you have a dual-boot machine like I do, try to measure under Windows too.
> ------- > John, this is what's to be expected, since your computer > is 10 times faster than mine. > > You can't compare results from two very different machines. Sure, but I am comparing relative figures, not absolute. For example ratio stringExtent / drawLine My test: 7367 / 999 = 7.3 Your test AA: 651667 / 31482 = 20.7 This cannot be explained by the relative speed of processors. Everything else being equal, one would expect the same ratios, right ? I will do a test with Motif some time later on. Unfortunately I do not have a dual boot PC.
I've repeated the benchmark on my PC where Eclipse is very sluggish, and now I see why :-( My configuration: * Mandrake Linux 9.2 with libfreetype 2.1.6 with true type bytecode interpreter activated, and windows fonts imported, which means I have 368 .ttf files in my /usr/X11R6/lib/X11/fonts/drakfont/ttf directory (which is of course included in the font path) * Athlon XP 2600+ * 512 MB RAM * NVidia GEForce256 with NVidia drivers * eclipse started with export GDK_USE_XFT=0 * benchmark run from eclipse, thus not using aa fonts Here is my results (when a test has a "single string" mark it means it is the original test, whilst the same test without this comment is the one corrected with the code posted in comment #51, that is, not using the same string twice) gc.setLineWidth 278 gc.getLineWidth 2185 gc.drawLine 3790 gc.drawText 17818 gc.drawText 2 18298 gc.stringExtent 89631 gc.stringExtent (single string)57 gc.textExtent 89344 gc.textExtent (single string)56 gc.drawOval 341 gc.fillGradientRectangle 3016 gc.drawImage 733 canvas.getSize 197 canvas.setSize 10 canvas.getClientArea 190 canvas.getBounds 307 canvas.computeSize 1010 canvas.computeTrim 576 As you can see my StringExtent/drawline ratio is around 20, too.
I've just run the same test agains SWT-FOX 2.1.1... well, it proves that it's not the PC, but either SWT-GTK or GTK itself have definitely something wrong inside (oh, the single string test has been fixed since it was performing a single call whilst the previous one was calling the method twice): SWT-GTK 3.0.0 SWT-FOX 2.1.1 gc.setLineWidth 279 137 gc.getLineWidth 2127 50 gc.drawLine 3663 3222 gc.drawText 18054 1960 gc.drawText 2 18621 2011 gc.stringExtent 90551 5246 gc.stringExtent(ss) 118 4593 gc.textExtent 89390 10485 gc.textExtent (ss) 115 9641 gc.drawOval 345 315 gc.fillGradientRectangle 3009 6875 gc.drawImage 750 551 canvas.getSize 186 179 canvas.setSize 10 5 canvas.getClientArea 189 178 canvas.getBounds 296 298 canvas.computeSize 913 502 canvas.computeTrim 602 205 As you can see FOX is 10 to 20 times faster as far as text is concerned, and a whopping 40 times faster for the getLineWidth method. Oh, some other information: running on j2sdk1.4.2_01 and KDE, gnome is not installed.
I've just run the same test using the Eclipse 2.1.2 libraries: gc.setLineWidth 275 gc.getLineWidth 3326 gc.drawLine 3302 gc.drawText 12027 gc.drawText 2 12465 gc.stringExtent 89928 gc.stringExtent (single string)80964 gc.textExtent 89536 gc.textExtent (single string)80351 gc.drawOval 326 gc.fillGradientRectangle 3021 gc.drawImage 725 canvas.getSize 233 canvas.setSize 10 canvas.getClientArea 193 canvas.getBounds 297 canvas.computeSize 11556 canvas.computeTrim 13472 Most of the times improved, but the drawText call is slower in 3.0 M6. In fact using 2.1.2 the text seems to scroll a little better in the editor. Looking at the source, it seems that swt 3 is doing a lot more work in the drawtext methods (such as painting the background of the rectangle that will be occupied by the text, if I understand the code properly)
I've found a mail thread that can be of interest to swt developers, where a scintilla developer is complaining about pango slowness. Some performance hints are included: http://mail.gnome.org/archives/gtk-devel-list/2003-March/msg00095.html
Some profiling information should help in pinpointing this: 1. Download and install OProfile from "http://oprofile.sf.net". 2. Collect a profile for something that runs slow with SWT/Gtk+ but fast with SWT/non-gtk+. I'd guess attachment 2 [details] above might be your friend. 3. Look at the results to find out where the time is spent: In the Java VM? In that case the fault is probably with SWT. OProfile doesn't speak Java AFAIK, so this would require some other tool to track down. If the hot spot(s) are outside the Java VM, find out which functions are the hottest. You may have to get / build / install GTK+, SWT and other libraries with debug symbols to get good data. There is a cheat sheet for OProfile at "http://oprofile.sourceforge.net/docs/". Happy profiling :-).
Well, I've oprofiled the swt benchmark I used in the previous posts, but unfortunately I can't find the packages that contains debug symbols for pango and gtk, anyway, here is the results, hope they may be of some usefullness (by the way, I'm running swt 2 at the moment). I can run the tests against swt3 if you like. Here is the top of the opreport -l output (I started oprofile just before starting Benchmark.java and stopped it after it finished, kernel profiling is disabled). CPU: Athlon, speed 2075.06 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 100000 samples % app name symbol name 2152019 25.5739 libpango-1.0.so.0.200.5 (no symbols) 1315371 15.6315 libglib-2.0.so.0.200.3 (no symbols) 1228633 14.6007 libc-2.3.2.so (no symbols) 759546 9.0262 libpthread-0.10.so (no symbols) 587952 6.9870 no-vmlinux (no symbols) 573590 6.8164 libgobject-2.0.so.0.200.3 (no symbols) 437056 5.1938 libpangox-1.0.so.0.200.5 (no symbols) 237193 2.8187 pango-basic-x.so (no symbols) 155944 1.8532 libjvm.so jni_SetShortField 112665 1.3389 libjvm.so jni_SetIntField 83596 0.9934 libswt-pi-gtk-2135.so setGtkStyleFields 61986 0.7366 libqt-mt.so.3.1.2 (no symbols) 52500 0.6239 libjvm.so jni_GetIntArrayElements 49883 0.5928 XFree86 (no symbols) 44982 0.5346 libjvm.so jni_ReleaseIntArrayElements 38790 0.4610 libjvm.so jni_GetByteArrayElements 32299 0.3838 libjvm.so jni_ReleaseByteArrayElements 31672 0.3764 libjvm.so jni_GetCharArrayElements 29180 0.3468 libgdk-x11-2.0.so.0.200.4 (no symbols) 22947 0.2727 libjvm.so arrayOopDesc::header_size(BasicType) 21693 0.2578 libswt-pi-gtk-2135.so Java_org_eclipse_swt_internal_gtk_OS_g_1utf16_1to_1utf8 19639 0.2334 libgdk_pixbuf-2.0.so.0.200.4 (no symbols) 18859 0.2241 libjvm.so jni_ReleaseCharArrayElements 18856 0.2241 libX11.so.6.2 (no symbols) 17158 0.2039 libjvm.so os::malloc(unsigned int) 14259 0.1694 oprofiled opd_lookup_maps 14201 0.1688 libjvm.so Runtime1::arraycopy(int, int, oopDesc *, int, oopDesc *) 13999 0.1664 libkdecore.so.4.1.0 (no symbols) 13344 0.1586 libswt-pi-gtk-2135.so Java_org_eclipse_swt_internal_gtk_OS_pango_1layout_1get_1size 12050 0.1432 libjvm.so os::free(void *) 11967 0.1422 libjvm.so jni_GetIntField 10330 0.1228 libswt-pi-gtk-2135.so Java_org_eclipse_swt_internal_gtk_OS_pango_1layout_1set_1text 8241 0.0979 oprofiled odb_insert 8099 0.0962 java (no symbols) 7379 0.0877 libjvm.so arrayKlass::oop_is_array(void) const 6974 0.0829 libjvm.so SystemDictionary::oops_do(OopClosure *) 6573 0.0781 libswt-pi-gtk-2135.so BII::Java_org_eclipse_swt_internal_gtk_OS_memmove_(void) 6195 0.0736 libgtk-x11-2.0.so.0.200.4 (no symbols) 5847 0.0695 libswt-pi-gtk-2135.so setGdkGCValuesFields 5616 0.0667 libswt-pi-gtk-2135.so getGdkGCValuesFields 4567 0.0543 libswt-pi-gtk-2135.so Java_org_eclipse_swt_internal_gtk_OS_g_1free 4537 0.0539 libcrypto.so.0.9.7 (no symbols) 3996 0.0475 oprofiled opd_put_image_sample 3727 0.0443 oprofiled opd_put_sample 3703 0.0440 libjvm.so anonymous symbol from section .plt 3552 0.0422 libjvm.so jni_GetShortField 3251 0.0386 libjvm.so typeArrayKlass::oop_is_typeArray(void) const 3089 0.0367 libswt-pi-gtk-2135.so Java_org_eclipse_swt_internal_gtk_OS_PANGO_1PIXELS 3020 0.0359 libstdc++.so.5.0.5 (no symbols) 3019 0.0359 bash (no symbols) 2952 0.0351 oprofiled opd_get_proc 2891 0.0344 libjvm.so AbstractInterpreter::notice_safepoints(void) 2507 0.0298 libjvm.so CompactibleFreeListSpace::totalSizeInIndexedFreeLists(void) const
Obviously about 60% of the CPU time is spent doing GTK+ related stuff, with Pango in a clear lead. However, to make this useful for the GTK+ guys however, I'd say this needs to be run with non-stripped versions of at least pango and glib. I don't know about Mandrake, but on a Debian system you could install them by doing "apt-get install libgtk2.0-dbg libpango1.0-dbg libglib2.0-dbg". Mandrake probably has something similar. If not, you'll have to build the libraries from source (available from "http://www.gtk.org/download"). Then, assuming you have your non-stripped libs in /usr/lib/debug, start your benchmark run using "LD_LIBRARY_PATH=/usr/lib/debug java ...". If all goes as planned, that should give you a lot more function names in the profile.
I can't find the debug packages for Mandrake anywhere, sorry. I took into consideration the native bench posted on http://bugzilla.gnome.org/show_bug.cgi?id=129473 I've modified it so that it renders the string "SWT is fast" instead of the string "0124567", and so that it sets the font and color attributes of the text. Result: the bench says it can layout and draw 17000 of those strings per second. And moreover, it it faster when xft is enabled. The swt version is capable of only 8000 strings per second, and according to the profile reported above this is not due to jni. It would be nice if swt developers could have a look at the source of this benchmark and see if there is some hints about how optimize the code. My impression is that Pango is not fast, but maybe the way swt uses it is not optimal...
Created attachment 7305 [details] Layout test I write simple test for some layouts. It seems layouting works same on both platforms Windows and Linux/GTK. I have the result: Windows = 6749 Linux = 9697 +-100
Created attachment 7306 [details] Eclipse profile report I use profiler from http://eclipsecolorer.sourceforge.net/index_profiler.html Some results you can see in this attach. As you can see must timeconsuming method is checkWidget (see methods.html) For profiling I start the eclipse, turn on profiling and do some actions like open popup menu, change tabs etc. Also I put statistics for startup (see startupStat*.html)
No, checkWidget is not the most time consuming method. It is the method that is called the most times, but since its very fast it doesn't mean a thing. The only odd thing I can find is the org.eclipse.swt.widgets.Display.getMessageCount method which should be fast too but definitely isn't. What version are you using?
Yes it's my misstake. checkWidget really just frequently called. I should sort by time not by calls number. You can import this files to the Excel and sort by taste. I use 3.0M6 BTW You can try this yourself. This profiler plugin very simple to use (just do not forget copy libProfilerDLL.so to the JDK_HOME/jre/liv/i386 dir).
Eclipse30 m6 SWT/GTK is even slower than m4. When I replace a text string in a source file I can see the changed lines flashing over my screen. Eclipse30 m6 SWT/GTK is unusable from a performance point of view. To support my feelings I have done a test to compare m4 and m4. I will upload benchmark.java which is benchmark of comments #7 and adapted with comments of #51. The test shows: - a remarkable improvement in gc.textExtent - substantial performance degrading in gc.drawOval and gc.drawImage Results are below: m6 m4 m6/m4 =========================================================== gc.setLineWidth 411 594 0.69 gc.getLineWidth 2904 2922 0.99 gc.drawLine 20326 16878 1.20 gc.drawText 47912 34903 1.37 gc.drawText 2 15832 8515 1.85 gc.stringExtent 161080 167721 0.96 gc.textExtent 152 3751 0.04 gc.drawOval 1626 196 8.29 gc.fillGradientRectangle 4114 4019 1.02 gc.drawImage 1519 364 4.17 canvas.getSize 329 331 0.99 canvas.setSize 17 17 1.00 canvas.getClientArea 348 344 1.01 canvas.getBounds 533 530 1.00 canvas.computeSize 1378 1380 0.99 canvas.computeTrim 910 910 1.00 Platform: SuSE Linux 8.2
Created attachment 7338 [details] Benchmark.java Benchmark test for SWT. Run instructions in source file. Add SWT jar files to classpatch. jar files can be found in Eclipse plugins folder.
Felipe, have we changed drawImage() or drawOval() for GTK between M4 and M6? My feeling is that the slow down between M4 and M6 (actually between Eclipse 2.1 and 3.0) is due to changes in Eclipse, not SWT. The biggest problem is that there are no benchmarks for Eclipse. These benchmarks that measure low level SWT operations are useful to optimize graphics but miss the big picture. For example, if string measure and draw time were zero, would Eclipse get faster? That's something we should try.
Steve, take 2.1 and install stw-fox, or take any other version using Motif. It is a lot more responsive, so the answer to your question is: yes, it is visibly faster. That said, profiling eclipse using hprof (which slows it down quite a bit) I could see Eclipse repaint the same thing as much as 4 times (outline, tab title), so I guess the is some event handling problem and/or some high level code inefficiency. Another issue is that when you switch from one editor to the other, the outline and navigator get repainted before the text editor (which stays completely gray for as long as a second, usually 0.5 seconds more or less), which is a problem because it's the thing that you're looking at while switching. The only way to improve text handling is, I fear, to create an LRU cache of layouts (I've looked at the source code as saw no other obvious way to improve the performance). But I would like to see also better event handling (in gtk forums I see words such as "event priority", so there should be a way to change the order events are handled I guess). I would like better to have a working SWT-Fox implementation, since it's fast, and I would not get native look anyway (I'm a KDE user)
A bit off-topic, but nevertheless: > I would like better to have a working SWT-Fox implementation, since it's > fast, and I would not get native look anyway (I'm a KDE user) The only way this can happen is by contributing. SWT/Fox is a part-time project of mine, so the more people getting involved in it, the faster progress you'll see. Sorry for the shameless plug.
I noticed that some people were seeing performance differences between GTK and FOX and others weren't, so i wanted to add my 2 cents. System: Pentium 4 2.8Ghz 533FSB 1 GIG RAM GeForce MX 420 Gentoo Linux 1.4 (2.4.24 Kernel, no NTPL) GTK 2.2.4 Eclipse 2.1.2 KDE 3.1.4 XFree 4.3 EclipseGTK is slow as molases, for example switching between two different perspectives takes about 1 second and you can clearly watch the window go from total gray, to individually repainting the separate internal windows then a final blink where the screen redraws. The text editor is VERY slow. If I select a lot of text and hit tab to indent, i can see the entire editor invalidate the text, move it, and recolor everything. NOW, when I installed/ran with SWT-FOX it was insanely fast. I would as fast IF NOT faster than Windows. Things just SNAPPED up. It was strange, but switching between perspectives was instantaneous, I saw NO redrawing at all. I'm not saying Switch to Fox, I'm just curious if this helps some people narrow down maybe why some of us are seeing piss-poor performance and others are seeing even performance across the board.
Created attachment 7344 [details] PI version of OptionPane Steve, here is the PI version of OptionPane, it does perfom a little better than the SWT version.
Yes, the PI version is a bit faster to paint than the SWT one but not that much. Please get to the bottom of this. Thanks.
Clemens, in your original example, could you replace the lines: while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } by: org.eclipse.swt.internal.gtk.OS.gtk_main(); How does this change affect the paint performance ? After this change when you drag another window over the swt app is the paint any better ? Thanks, Felipe
Although in my machine (IntelliStation Z Pro, Dual Xeon processor) the changes I tried today did improve the performance a little bit they didn't help in a slower machine (NetVisa, Single P4) therefore you can disregard my last results (OptionPanePI faster than OptionPaneSWT).
Benchmark.java results: Windows System: Windows XP, SP1 Eclipse 2.1.2 Pentium 4 2.4Ghz GeForce 3 Results: gc.setLineWidth 1406 gc.getLineWidth 1297 gc.drawLine 6531 gc.drawText 3688 gc.drawText 2 2390 gc.stringExtent 2844 gc.textExtent 7110 gc.drawOval 1203 gc.fillGradientRectangle 234 gc.drawImage 1422 canvas.getSize 765 canvas.setSize 3125 canvas.getClientArea 797 canvas.getBounds 1188 canvas.computeSize 1828 canvas.computeTrim 1531 I will run this benchmark at work (on the slow setup I was mentioning) and post the results here as well.
I guess this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=38937 deals with the same problem.
It's not clear that it does. The Java text editor is based on StyledText but add tons of other behaviors. StyleText scrolls reasonably well on all platforms.
One of the styled text problems is that it triggers the computation of thousands of pango layouts (GTK text handling, the very slow part in the benchmark.java test). On my PC scrolling is barely reasonable, but not fast (I can see it redraw the bottom of the page while scrolling down). Can you provide an example like the java text editor in which the style changes every few word? (this is the problem, pango wise, it has been "optimized" to compute layout for paragraps, not for a few words)
UPDATE: Benchmark.java results: Windows System: Windows XP, SP1 Eclipse 2.1.2 Pentium 4 2.4Ghz GeForce 3 Linux System: Gentoo Linux (Kernel 2.4.24) Eclipse 2.1.2 Pentium 4 2.8Ghz GeForce 420MX XFree 4.3 GTK 2.2.4 Windows Results: gc.setLineWidth 1406 gc.getLineWidth 1297 gc.drawLine 6531 gc.drawText 3688 gc.drawText 2 2390 gc.stringExtent 2844 gc.textExtent 7110 gc.drawOval 1203 gc.fillGradientRectangle 234 gc.drawImage 1422 canvas.getSize 765 canvas.setSize 3125 canvas.getClientArea 797 canvas.getBounds 1188 canvas.computeSize 1828 canvas.computeTrim 1531 Linux Results: gc.setLineWidth 270 gc.getLineWidth 2367 gc.drawLine 2817 gc.drawText 12236 gc.drawText 2 5721 gc.stringExtent 93307 gc.textExtent 42067 gc.drawOval 303 gc.fillGradientRectangle 2712 gc.drawImage 506 canvas.getSize 312 canvas.setSize 12 canvas.getClientArea 267 canvas.getBounds 418 canvas.computeSize 7574 canvas.computeTrim 7024 Side by Side Comparison (units in ms): Method Windows Linux Result (by a factor of) ------------------------------------------------------------------ gc.setLineWidth 1406 270 Lin faster (5.2x) gc.getLineWidth 1297 2367 Lin slower (1.8x) gc.drawLine 6531 2817 Lin faster (2.3x) gc.drawText 3688 12236 Lin slower (3.3x) gc.drawText 2 2390 5721 Lin slower (2.4x) gc.stringExtent 2844 93307 Lin slower (32.8x!) gc.textExtent 7110 42067 Lin slower (6.0x) gc.drawOval 1203 303 Lin faster (3.9x) gc.fillGradientRectangle 234 2712 Lin slower (11.6x!) gc.drawImage 1422 506 Lin faster (2.8x) canvas.getSize 765 312 Lin faster (2.4x) canvas.setSize 3125 12 Lin faster (260.4x) canvas.getClientArea 797 267 Lin faster (3.0x) canvas.getBounds 1188 418 Lin faster (2.8x) canvas.computeSize 1828 7574 Lin slower (4.1x) canvas.computeTrim 1531 7024 Lin slower (4.6x) I appologize this test was against two unequal processors, but keeping in mind that the Linux machine is 400mhz faster, it makes the differences on "stringExtent" and "textExtent" even more important to look at. Had my home machine been equal in speed, I imagine that speed gap would be even larger. Please let me know if there is more I can do to help, this problem is very important to a lot of people to fix.
AMD Athlon(tm) XP 2500+ MemTotal: 1034456 kB Nvidia GF FX5900 Gentoo Linux Kernel 2.6.0 XFree86 Version 4.3.0 Gnome-2.4.1/gtk+-2.2.4 Eclipse 2.1.2 java version "1.4.2_02" gc.setLineWidth 306 gc.getLineWidth 3717 gc.drawLine 3056 gc.drawText 22248 gc.drawText 2 11530 gc.stringExtent 69913 gc.textExtent 29856 gc.drawOval 336 gc.fillGradientRectangle 2740 gc.drawImage 404 canvas.getSize 213 canvas.setSize 12 canvas.getClientArea 226 canvas.getBounds 350 canvas.computeSize 11848 canvas.computeTrim 11422
Andrea, it's not the same code base at all but can you try a large slow Java file (like StyledText.java) in the Eclipse and in the org.eclipse.swt.examples.javaviewer.JavaViewer and let is know the results? Thanks. Tell us what file you used so we can repeat the experiment. I'm planning to "Malkovich" all the string operations in SWT and see if Eclipse on GKT gets any faster. I need a very specific set of steps that is slow on GTK and fast on Windows. Anybody? Will scrolling do? If so, we must agree on the file.
Linux System: SuSE Linux 7.2 (Kernel 2.4.19) Eclipse 3.0 M6 Athlon 1.4 GeForce ?? XFree 4.2 GTK 2.2.4 gc.setLineWidth 951 gc.getLineWidth 4381 gc.drawLine 4987 gc.drawText 38872 gc.drawText 2 8209 gc.stringExtent 194553 gc.textExtent 113 gc.drawOval 507 gc.fillGradientRectangle 4078 gc.drawImage 746 canvas.getSize 811 canvas.setSize 27 canvas.getClientArea 792 canvas.getBounds 1473 canvas.computeSize 3687 canvas.computeTrim 2923 Benchmark ready: disposing of gc
Wow, anyone noticed in comment #85 how fast the textExtent operation was under Linux, while in many other people's reports (including mine) it was quite a bit longer (~25seconds)?
To Riyad: That's just because the Benchmark.java test attached to this bug report is still using just one string with the TextExtent code, if it used two strings it would be as slow as ours. To everybody: pango is slow, but notice that is much slower if you are using an Nvidia graphic card (see how people with ATI graphic cards get faster results than ours). Most of the people using Linux I know does own an NVidia card thought because it had the drivers before ATI provided them. See for example http://mail.gnome.org/archives/gtk-devel-list/2003-March/msg00098.html, but there are other threads. Even with the render acceleration activated pango gets lower performance than with ATI graphic cards (which is pretty much slow anyway)
Created attachment 7389 [details] Benchmark2.java Obsoletes Benchmark.java. Added extra line to gc.textExtend() method.
Created attachment 7390 [details] build.xml Ant build file to run Benchmark2.java. Sets required jar files and VM parameter. Change: swt.dir = path to SWT jar files. jvmarg= path to SWT dynamic load libraries.
I've extended the benchmark to measure the speed of getting and setting colors and fonts. motif gtk gtk Win98 AA not AA gc.getForeground 2879 266 259 0 gc.setForeground 9 47 52 0 gc.getBackground 2880 252 243 0 gc.setBackground 16 67 58 0 gc.getFont 2240 2 2 0 gc.setFont 6 79 75 50 Maybe it would be an idea to cache colors and font, so a request for these value doesn't have to go all the way through JNI and X. X is a client/server architecture and as long as you send commands to X it's very fast, but when you request something it's becomes slow. So the secret is: Don't ask, just do it! (It almost sounds like a commercial for some sports wear :-) )
Are you sure that drawing operations is the source of the swt-gtk low performance? To resolve this problem we should find the real bottleneck in the code first. Is there any proof that gc.* operations take most run-time?
An other interesting feature in this ongoing saga. The KDE theme makes a huge difference in responsiveness of the menus. For example using theme Keramic the dropdown menus are slow, especially the File menu. However using theme "KDE default" the menus are really fast. The benchmark test shows a remarkable difference in speed for setLineWidth and getLineWidth between the 2 themes. Ensure you logoff from KDE after changing theme as for some reason Eclipse otherwise does not pickup the new theme, not even after a restart of Eclipse. Benchmark: using KDE theme "KDE default" [java] Benchmark start [java] gc.setLineWidth 445 [java] gc.getLineWidth 2942 [java] gc.drawLine 20274 [java] gc.drawText 47820 [java] gc.drawText 2 15804 [java] gc.stringExtent 167901 [java] gc.textExtent 155 [java] gc.drawOval 194 [java] gc.fillGradientRectangle 3926 [java] gc.drawImage 376 [java] canvas.getSize 325 [java] canvas.setSize 16 [java] canvas.getClientArea 338 [java] canvas.getBounds 515 [java] canvas.computeSize 1403 [java] canvas.computeTrim 937 [java] Benchmark ready: disposing of gc Benchmark: using KDE theme Keramic, which uses aplha blending [java] Benchmark start [java] gc.setLineWidth 1420 [java] gc.getLineWidth 4310 [java] gc.drawLine 20058 [java] gc.drawText 48095 [java] gc.drawText 2 15718 [java] gc.stringExtent 168218 [java] gc.textExtent 159 [java] gc.drawOval 205 [java] gc.fillGradientRectangle 3792 [java] gc.drawImage 386 [java] canvas.getSize 335 [java] canvas.setSize 20 [java] canvas.getClientArea 373 [java] canvas.getBounds 532 [java] canvas.computeSize 1408 [java] canvas.computeTrim 952 [java] Benchmark ready: disposing of gc
Answer to #91: No I'm not absolutely sure that drawing operations are to blame, but the only difference between the fast Motif and the slow GTK editions are different SWT implementations. So I still think we shall find the course of the problem somewhere in SWT, GTK or a combination of the two. When we scroll through a java file in the editor a lot of things are going on behind the scene, but this behind-the-scene thing is also going on in the Motif and Windows edition, and as you all know aren't slow at all. Answer to #92: I can't see how the choicen KDE theme has anything to do with our speed problem. KDE is based on QT, a completely different toolkit and isn't used at all when we use GTK drawing operations. Try the benchmarks a couple of times and see if the difference you see in setLineWidth and getLineWidth is consistent.
[quote] I can't see how the choicen KDE theme has anything to do with our speed problem. KDE is based on QT, a completely different toolkit and isn't used at all when we use GTK drawing operations. Try the benchmarks a couple of times and see if the difference you see in setLineWidth and getLineWidth is consistent. [/quote] After repeating benchmark the average speed is the same between theme Keramic and KDE. However there IS a huge difference in speed of the IDE, which does not show up in the benchmark. - menus under theme KDE are instantly visible, while with theme Keramic there is always a delay, sometimes half a second or more. - scrolling in navigation panel or editor works fine under theme KDE, while it becomes a smur under Keramic. Under theme Keramic I cannot use the scrollbar, only the wheeelmouse as otherwise everything becomes a smur.
Answer to #93: SWT is not only drawing operations and GTK used not just for drawing. So, the problem of SWT-GTK may be not the drawing performance even drawing operation on SWT-GTK can be significaly slower then one on other platforms. Is there anybody who make profiling of swt? Which methods of SWT spend most time?
Making general changes in a file in the Java Editor under M6 is significanlty slower than under M4. Has there been a change in the way the editor works between M4 and M6 ? For example each changed line is highlighted under M6 for each and every change on that line. For example if I take a document of a few hundred lines and I change "a" to "a1" I can literally follow each and every change on the screen. This is not the case with M4 or with M6 Motif. They are ready instantly. It looks to me that highlighting a line while the editor makes changes is completely unnecessary. It makes the editor unbearably slow when making general changes.
@comment 96: Yes, the amount of work done in the PostSelectionEvent has grown considerably with M5 (background highlighting and other cool but costly stuff). See bug 48034 for details (and note the improvents for the next integration build...).
So far I've seen people complain on every platform of M6's performance. Aparently something drastic changed behind the scenes :(
Regarding with GTK performance vs theme see Bug#46323.
UPDATE: Linux System: Gentoo Linux (Kernel 2.4.24) Eclipse 2.1.2 Pentium 4 2.8Ghz GeForce 420MX XFree 4.3 GTK 2.2.4 Benchmark 2 Results: Benchmark start gc.setLineWidth 271 gc.getLineWidth 2111 gc.drawLine 2660 gc.drawText 11685 gc.drawText 2 5579 gc.stringExtent 101553 gc.textExtent 41227 gc.drawOval 71 gc.fillGradientRectangle 3235 gc.drawImage 271 canvas.getSize 281 canvas.setSize 11 canvas.getClientArea 265 canvas.getBounds 414 canvas.computeSize 8162 canvas.computeTrim 7413
Is there ANY activity going on with this bug? So far I've seen the developers ask the users to profile the code, and seen the users report back benchmark results and Andrea give some good profile information but no one really ran with it... Can the developers tell us what they need for this bug to move forward? (Us users can be very helpful when we choose to be :)
Not sure what to say. There have been Eclipse changes in M6 that have made Eclipse slower on every platform. We have optimized some of the benchmarks are are open to any code you want to provide HOWEVER, we will not put in random code without numbers or Eclipse scenarios that show improvement. For example, try changing getLineWidth() to return 0 and making setLineWidth() to nothing. The code is wrong, bug fast. Does Eclipse painting in a StyledText get any faster on GTK? What happened about comment 84? Is a plain old StyledText that does syntax coloring slow on GTK versus the Java editor in Eclipse?
I've just tried scrolling thru StyledText.java in the normal eclipse java editor and in org.eclipse.swt.examples.javaviewer.JavaViewer on my old dinosaur (a 233 MHz PII), and they are equally fast (or slow). Then I tried to profile the example JavaViewer. In this JavaViewer I opened the java file "StyledText.java" and scrolled down to the bottom and up again with the PageDown and PageUp keys. The result of this profiling surprised me, because it's NOT gc.drawText or gc.textExtent that was eating all my CPU power. Actually they used less than 10% of the time. The two methods that used the most CPU time was: org.eclipse.swt.widgets.Control.update 28.73 % org.eclipse.swt.widgets.Display.eventProc 17.93 % I don't know what that means, but I guess it has something to do with how the message queue are handled. I've attached the profile.
Created attachment 7463 [details] Profiling JavaViewer
Refer to link: https://sourceforge.net/forum/message.php?msg_id=2306557 Can somebody check if problem with TextLayout mentioned here is related to slow GTK performance ? Sun is going to fix problem with TextLayout in JDK 1.5. Maybe this fixes GTK problem as well.
I dont think so, it seems that this stuff is only related to java toolkits based on j2d.
The point is that there is a bug in the way text is rendered by TextLayout. If text is rendered optimized or not depends on an other class. It can well be that optimized or not depends on the platform. If that is true, and text is not rendered optimized on GTK this may well explain why GTK is slow. If the component returns optimized text for Windows this will be rendered fast. In that case a workaround for this bug can be made to the current version of Eclipse, whithout waiting for JDK 1.5 That is why I would love to see someone from IBM to have a look at this bug to see if it applies to the GTK performance issue. BTW: using theme KDE in stead of Keramic makes a huge difference in performance. The difference between mostly very slow and only a tick slow when changing perspective. -- John Zoetebier Web site: http://www.transparent.co.nz
Answer to comment #105: No, SWT does not use java.awt.font.TextLayout, therefore it does not affect our code. We are working on our own implementation of TextLayout (Bug#39881), currently StyledText is been modified to use this new resource. Although the main purpose of this work is BiDi (and complex script) enablement for GTK/Carbon it also has one eye on performance, but is still to early to claim any improvement.
In an effort to help provide details, I changed my KDE theme to be KDE default, and even tried simpler ones like QT Windows and so forth, these had no impact on how fast/slow Eclipse ran. I even tried different window decorations, turned off all effects, have no Anti aliasing, etc... none of this helped.
That doesnt suprise me at all, because QT doesnt have any effect on how fast GTK programs are. Maybe some people are talking about kde-themes because SuSE installs a GTK-Theme which look similar to the KDE-Keramik theme but is really awfully slow. So siabling the GTK THEME improves performance, on my 1,6G-P4 eclipse was nearly twice as fast but SWT programs (also self written) are much slower than native GTK/C programs. GTK must be used in a wrong way, another strange thing is, that X needs most of CPU-time, so that does mean that the bad code is not in GTK, its in X and its so slow because through SWT GTK uses X the wrong way. However X is sh***...
>In an effort to help provide details, I changed my KDE theme to be KDE default, >and even tried simpler ones like QT Windows and so forth, these had no impact >on how fast/slow Eclipse ran. >I even tried different window decorations, turned off all effects, have no Anti >aliasing, etc... none of this helped. This depends on the way KDE is setup to affect GTK. On SuSE 8.2 the default settings is set to affect GTK. You can change the setting via Appearances > Colors > Apply colors to non-KDE applications. If switched on you will find in home directory file .gtkrc-kde After switching theme you must logoff and on again to make the settings available to GTK applications like Eclipse. Themes can be found under Appearances > Windows decorations. It really makes a huge difference on my AMD 2000+ box with 512 Mb RAM.
As a note, Bug 49524 and Bug 50131 deal with some performance issues that are not platform-specific.
Don't know if the data help... Linux System: Mandrake Linux 9.2 (Kernel 2.6.1) Eclipse 2.1.2 Pentium 3 600Mhz, 1G Memory NV11 Geforce2 MX/MX 400 glibc-2.3.2-14mdk XFree86-server-4.3-24.1.92mdk gtk+2.0-2.2.4-2mdk Benchmark 2 Results: gc.setLineWidth 1963 gc.getLineWidth 22879 gc.drawLine 4758 gc.drawText 112351 gc.drawText 2 22031 gc.stringExtent 408174 gc.textExtent 147974 gc.drawOval 252 gc.fillGradientRectangle 13182 gc.drawImage 1309 canvas.getSize 867 canvas.setSize 38 canvas.getClientArea 868 canvas.getBounds 1502 canvas.computeSize 37520 canvas.computeTrim 34989 Benchmark ready: disposing of gc
What really gets me about this bug is that its such an obvious problem for anyone using Eclipse-GTK on Linux that I can't believe its not making the developers crazy while they are using it all day long (its making me loopie) Autocomplete, selection, scrolling, switching perspectives, indenting... pretty much everything is about 5x slower than on windows. For example, if I select 4 lines of code and hit tab on Windows, it *looks* like my 4 lines move forward, unchanged. On linux, I actually watch the entire syntax highlighting invalidate, my 4 lines move forward, the entire editor repaint itself then scroll back down to the point where my cursor is (from what seems to be the top of the file) and then I watch the syntax highlighting reevalutae and repaint all the tokens in the visible screen. Total time is about 350ms->500ms. This is on a 2.8Ghz P4 with 1 Gig of ram. I run NetBeans on Linux because Swing is about 2x-3x faster on Linux, how backwards is that? The whole thing about SWT... well nevermind you guys know, I'm preaching the choir here. So to recap, Eclipse-GTK on Linux is horrific (hell even Motif isn't much faster) and I can't for the life of me figure out how the developers and users are not complaining about this constantly. To make a comparison, its like having the best car mechanic in town as a husband, and all the cars he fixes run like a dream, but his own car is falling apart. A 3rd party might look at that and go "I don't get it, how can he be so good at fixing cars and having the terrible car he does, doesn't make him nuts?!" But, if I find out that all of OTI and IBM are running on Windows, well then I can understand why this is such a sluggish issue to investigate. I am tending to agree with the comments of people that say "XYZ is MISUSING ABC technology". It really seems that way. SWTFox is fast as hell, so it can't be X windows that is the problem, because other apps run fine (KDE/Gnome apps). It can't be GTK because Gimp/Gnome runs fine. So it *seems* like SWT is doing something maybe more generic than it should, that is just horrifically painful for GTK to ask X windows to do. So something along the lines of "repaint the editor when a keypress occurs to update syntax tokens", well in Java that sounds fine and repainting is cheap just for the visible rectangle... but unknowingly SWT might be calling a routine or series of routines in GTK that actually cause it to recalculate and repaint the entire editable area, which in turn makes GTK turn around and assult X-windows for processor time. I really don't know, just trying to give a feel for maybe the pattern of what is happening. There are a LOT of CC's on this list, can any of you set aside a day (or 2) to trace/profile the execution stream with a debugging version of GTK from a key event in the editor window, all the way down the chain, into GTK, and back to the repaint? I'd be curious if it was something very simple or if there is some better GTK way to handle this. I don't want to sound gruff and accusing towards anyway, I'm the last one that should criticize on this CC list here, I just really want to figure out what the heck is going on with such an aparent and strange bug/issue/whatever.
FYI, the posts from #112 are very interesting. One of the devs mentioned during profiling finding that keypresses were causing 750KB of garbage to be created... wow. Also people are reporting Linux with M6 is like mollases and others are reporting the same on Mac OS X. Just wanted to point people to these other threads if they are interested.
Several things: Steen, can you compare StyledText.java and in org.eclipse.swt.examples.javaviewer.JavaViewer on a fast machine. Your dinosaur is interesting but I bet GTK itself is pretty slow on it. For example, how does the "wordpad" program (whatever it's called) compare using the same Java colored text. I'm sorry I can't do more with your profile. Try commenting out update() in the SWT source. Is performance better? Riyad, I am well aware of the problem and I am also loopie over it. We are all maxed out on everything else, including EclipseCon. To really solve this, one needs to be intimate with all of the Eclipse code, not just SWT. Focusing on "string drawing", while interesting, doesn't seem to capture it all. I agree that SWT is involved somewhere but it is elusive. What exactly is Eclipse doing when you hit the Tab key. Can you try running another Eclipse under debug and suspending some other threads? Does performance improve? A) Can someone confirm that Fox M6 is good? B) Do the following on GTK: 1) Window->Preferences->Java->Editor 2) Turn off EVERYTHING (Yes, EVERY Java Editor Feature, don't miss hovers) 3) Window->Preferences->Java->Work in Progress 4) Turn off EVERYTHING 5) Is typing fast? C) Get a nightly GTK build and try it. Has performance improved since M6? This is all I can do for now.
Steve thank you for the reply, I will try those as soon as I get back into work and report back here. I did read those long threads about the hovering being a bane of many people's existence and it getting fixed in the 1/16 nightly build, I'll try and check that out as well.
It makes me sad but I´ve to agree to Riyad Kalla´s post. On Linux SWT only causes problems, the only advantageis, that it has is the native look&feel, however because there are so many toolkits out there a native l&f even doesn´t exist on this platform. A second problem are the many dependencies. It depends on GTK2.0.6+ (and the whole stuff that belongs to GTK), a appropriate glibc-version, the compilier-abi should also be equal (I hat GCC for changing the ABI all the time - on windows I can link libs that were compilied with borland 4!). On my machines (P4-2,6, P4-1,6, Athlon-800) it feels slower than SWING in any case, and this does not depend on which GRX-board is inside. I´ve a Matrox-G400, a ati radeon mobility m6 and a geforce go 488 and its equaly slow on every machine compared to the processor-power. There is also the same problem that X eats up a huge amount of cpu-time, however native gtk2-apps are faster than all the qt-apps which are also quite slugish on the Althon800 when themeing is enabled. SWT makes sense especally on Windows where abis and apis are long-term compatible, on osx its better than on linux but its nearly the same desaster. Imagine someone tries to install a SWT-2.1 app on a linux machine in 5 years - oh my god. He must be lucky if the new GCC can compile the old gtk-2.x and all headers fits together - but forget it for plug&play software. So SWT destroys the biggest advantage on linux - the "all-included, just install java" advantage. The advantage that it should be faster is wrong. Swing on X is still very slow compared with the D3D/DDraw optimized java2D-rendering engine on windows, but netbeas is faster than eclipse. After Jitting some gui-code (which takes about 10 secs. normal work) the whole stuff runs fluently. Swing also is catching up and with 1.5 there will be a OpenGL optimized java2d renderer which will improve the speed of image-handling about 10-(inf. -1) times, depending on your card. The ugly metal-lnf will be replaced and even the alpha looks much better! In my opinion it would be best to help the project which tries to create a swing-port of SWT, so that there would be a 100% pure-java version of eclipse and the user could choose which version he want to use. GNOME/Linux users may choose the GTK vrsion because of integration, people who just want to use it will use the swing.version (if its nearly as slow/fast than swing). It would also help the companies using SWT as a basis for application development. For some platforms they could pack os-specific packages and for systems that would not be supported anyway they could produce a java-package which should be able to run on any java-1.x enabled platform. One advantage which doesnt interrest me at all is, that maybe sun also would choin eclipse when there would be a swing-version of swt, but as I said thats not interresting for me, maybe its tactically interresting. However, eclipse will destroy the commercial market for IDE sooner or later, at least the life for all non-ms companies will be much harder. What me makes so hopeless is, that it seems IBM-peolpe don´t know why its so slow nore that its really slow. It seems they ignore the fact, also ignoring that this bug has the 2nd place when comparing the votes. It seems they really use Win2000 at OTI. However, I hope you can find the reasons, good luck... lg Linuxhippy
Clemens, I really feel I need to comment on some of your points. SWT / GTK+ *does* give native look and feel to people using GTK+ based desktop environments. Obviously that's not everybody, but a lot of people do. Regarding SWT / GTK+ dependencies, GTK+ gets installed by default by all major Linux distros unless you explicitly say no or remove it. Yes, there are people running older distros, and they will have to build from source, but for each day fewer and fewer people have this problem. As for Eclipse depending on certain glibc versions, the 3.0 plan (at "http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_0.html#TargetOperatingEnvironments") says nothing about it. Where did you get that information? GCC changed the C++ ABI because it was recently standardized. That the C++ ABI hasn't been standardized until now is unforturnate, but hardly GCC's fault. Since this affects only C++ programs, I don't understand how that would be related to GTK+ (C), Eclipse (Java) or SWT (C?) in any way. Regarding Swing suddenly becoming 10 times faster, I just don't believe it. I have no trouble that number or higher can be proven in artificial benchmarks, but if it really improves that much for real-world use, that would surprize me a lot. I would guess resolving the SWT / GTK+ performance problems is probably a lot less work than getting SWT / Swing up to the same quality as SWT/GTK+ with the performance problems resolved. Regarding running ancient apps on Linux, I still have a copy of Netscape 4.7 which is 6 years old, and other than being ugly it still runs fine. Why would an SWT2.1 app in 5 years be any different? If you (or anybody else) feel like replying to this, please reply to me by e-mail. This post (and any replies to it) probably doesn't help resolving the problem.
Request from steve_northover@ca.ibm.com B) Do the following on GTK: 1) Window->Preferences->Java->Editor 2) Turn off EVERYTHING (Yes, EVERY Java Editor Feature, don't miss hovers) 3) Window->Preferences->Java->Work in Progress 4) Turn off EVERYTHING 5) Is typing fast? I switched off everything under all editor tabs and java as requested. Then did change "a" to "a1". Still slow as ever: I can literally see the cursor moving over the screen. Same test on M4 with default editor settings is fast.
@comment 114: the problem that you can see document changes line is due to Control.setRedraw not being implemented on X based platforms. See the following bugs for reference: bug 26153 - swt bug bug 44691 - smart tab bug 18955 - comment action
Tom, who is calling setRedraw()? That is guaranteed to make everything redraw on platforms were it is implemented, making things slower because the entire window redraws. Feel free to update the bugs with this information. John, are you sure you turned everything off? Also exit and come back. Also try closing the outliner view (exiting and coming back to make sure it is really gone). Please choose a file that we can both see, such as StyledText.java and make a screen shot. This will help us recreate the conditions you are seeing. Thanks.
Steve, the bugs mentioned state that setRedraw is not implemented on the X-based platforms. The editor / viewer usually wrap complex document transformations involving many small changes (like comment/uncomment, indent, format, etc.) into a pair of setRedraw(false), setRedraw(true) calls to avoid the user seeing the document being modified change by change. However, on X, setRedraw(true) causes the editor to be repainted and the editor top to flash for a fraction of a second, which is a pain. We therefore don't call setRedraw on X any longer, with the result that such a complex modification can be seen change by change (and a little slower, too). I don't think this is the problem here, though.
Tom, this may explain why I can see the user interface draw element by element sometimes, especially when changing perspective. Another thing which is very slow is indenting a big block of code: I can see it redraw the whole thing 5 to 6 lines at a time, all in all the whole indeting operation takes more than half a second...
I have exactly the same experience as comment #124 with changing perspective (takes about 1 second to switch entirely and 3/4 second to do the redrawing that I can watch panel by panel). Also the code indenting is horrific, same experience (redrawing, etc.)
Very interesting ... setRedraw() on GTK and Motif is not implemented. The code does nothing (other than update an internal flag). Can you look at your code again? Calling setRedraw(true) should do nothing on X. Assuming you are using a StyledText, all that setRedraw() does on Windows is stop drawing. All the code that measures strings, scrolls to the top etc. still runs on every platform. How about constructing a benchmark that captures your use of StyledText to see whether this is causing any performance problems?
As a note, I've attached a patch to Bug 26153 to implement the disabling of redraw on GTK. Maybe not the best solution, but it's enough to show responsiveness and performance problems.
Tried to build Eclipse from nightly CVS with: ./build -os linux -ws gtk -arch x86 -target run Then got this error: BUILD FAILED file:/home/johnz/eclipse_cvs/buildScripts/plugins/org.eclipse.jdt.core/build. xml:50: srcdir "/home/johnz/eclipse_cvs/buildScripts/plugins/org.eclipse.jdt. core/search" does not exist!
Created attachment 7575 [details] Snapshot Eclipse This snapshot shows Eclipse while replacing "a" to "a1" from file:/home/johnz/eclipse_cvs/buildScripts/plugins/org.eclipse.swt/Eclipse SWT Custom Widgets/common/org/eclipse/swt/custom/StyledText.java I have imported this file to a test project. This simple change takes more than 10 minutes ! My PC has AMD 2000+ PC with 512MB RAM While replacing I could. - take snapshots - write this massage And it is still not even half way through the change. The performance of M6 is so horrendously bad that the Eclipse has become unsuable from any practical point of view. I have not seen anything like this with any other program that even comes close. The program also seems to be eating memory as I hear the disk ratling whicj is unusual. There is definitely a problem the way Eclipse uses Java as java CPU is between 60 - 95% At the same time X use is around 2% So this is NOT a SWT problem to the best of my knowledge.
Created attachment 7576 [details] snaphot 3 An other snapshot
Thank you for the screenshot and report... can you download and try the SAME test with the latest nightly or integration build? quick link: http://www.eclipse.org/downloads/index.php
Created attachment 7577 [details] CPU usage This is a snapshot of CPU usage. As you can see Java uses 94% while X uses only 3% At this point in time Eclipse does not redraw anything anymore. The whole Eclipse screen is gray. At the same time other applications remain responsive. This means the the problem is in Eclipse only. BTW: my estimate of 10 minites to replace "a" into "a1" has been to optimistic. It is going in the direction of half an hour now.
Hi Riyad, I get an error building the nightly CVS build. The integration build is not available for Linux GTK.
Suggestion: Instead of going all the way thru Pango wouldn't it be simpler and perhaps faster to use the X11 functions Pango is using to draw and measure strings. Xft has (among others) the following functions: void XftDrawString8 (XftDraw *draw, _Xconst XftColor *color, XftFont *pub, int x, int y, _Xconst FcChar8 *string, int len ); void XftDrawStringUtf8 ( XftDraw *draw, _Xconst XftColor *color, XftFont *pub, int x, int y, _Xconst FcChar8 *string, FcEndian endian, int len ); void XftTextExtents8 ( Display *dpy, XftFont *pub, _Xconst FcChar8 *string, int len, XGlyphInfo *extents ); void XftTextExtentsUtf8 (Display *dpy, XftFont *pub, _Xconst FcChar8 *string, int len, XGlyphInfo *extents );
SSQ, it this an option?
Using only Xft ? Pango also has backends to other kinds of fonts (pangox, pangoft2) that means a GTK widget can use something else other than xft font. Besides, I didn't find any API on /usr/include/X11/Xft/Xft.h to itemize, reorder, cursors movement, styled drawing, recognize cluster, word wrap, level, etc, or am I missing something here ? Please, if you have some to add I would prefer to continue this discussion on Bug#39881. We plan to release this work on StyledText by Eclipse 3.0 M8, from M8 to M9 I expect to work on performance tunning of StyledText&TextLayout implementation.
It's only the implementation of GC.drawString, GC.drawText, GC.stringExtent and GC.textExtent I was thinking about, when I suggested to use direct Xft functions. Not cursor movement, word wrapping, BIDI etc.
Now that EclipseCon is over, have the dev's had a chance to look into this? (Actually has anybody has time to look into this?) My interest in this was set ablaze this morning while I was dragging the preference window around ontop of the Eclipse editor window and I was watching the Eclipse main window repaint itself in about 1/4 second intervals so I coul dget huge blocks of invalidate gray screen before the repaint occured, flickered the screen, and redrew the editor screen again... god this is really worse that Swing 1.0 which makes me think every more that its a "SWT is misusing GTK" issue... as none of X, GTK or SWT suck bad enough on their own to EVER produce redrawing anomolies in applications like the ones I am experiencing now. (Sys Info for Reference: Gentoo Linux (2.4.25), XFree 4.3, KDE 3.1.5, Eclipse GTK 2.1.2, GTK 2.4.2, P4 2.8 Ghz, 1Gig Ram, GeForce MX 440, Font AA turned OFF)
In querying the GTK bugs database I was unable to find any bugs related to performance or Eclipse that applied to redrawing speed or text layout, so I filed one using eclipse as a good test case for poor performance with GTK on linux. Please see the bug here: http://bugzilla.gnome.org/show_bug.cgi?id=135017 and comment on it if you have any findings that the developers might be interested in.
Owen (RedHat GTK dev) has been very accomodating over at the GTK bug report: http://bugzilla.gnome.org/show_bug.cgi?id=135017 and I'm wondering if there is something we can do to put together a good test case and benchmark results specific to Pango to hand over to him or the pango devs to look into? His last post gives an example of what he would want.
Have you till now not recognized that none of the eclipse-developers are interrested/working on this task? I hope they will be bothered enough when IBM switches from Win to Lin, so that they tune it for themselves. Maybe they ask IBM-managers if the may go on with Windows because Linux is so slow. I know its is NOT gtk+, because i tried out GNOME only because I wanted to know if GTK is everywhere so slow. I tries really big gtk apps like evolution and many others and they are unskinned even faster than QT with skin. What I would love to see would that SWING would get a official supported "platform". That would be much easier to do than a port to a new native toolkit, it would make eclipse download-once/run-everywhere and with 1.5 it even would look cool. I bet that this swing version would perform much better than gtk now does. Sad but true, no one is interrested here.
On the topic of having an SWT port that runs on top of swing, and hence being able to run Eclipse on any platform without the need for a platform dependent port of SWT, the SWTSwing project (http://sourceforge.net/projects/swtswing/) might be of interest. By the author's own admission the project is nowhere near complete enough yet to run Eclipse, but if some of you are interested enough in this issue you might be able to lend a hand. The project seems to be worryingly inactive now, with an activity percentile of 40.8706% on sourceforge, so if some people could mail the author and offer a helping hand it might kick-start the project and get something useable out of it pretty quickly. The SWT/FOX port also seems to be stagnating a bit now as well (I haven't seen any updates on the website for a while, and there doesn't seem to be any coherent strategy to support Eclipse 3.0 at the moment, which is my primary development platform at the moment). If anyone here is sufficiently skilled with FOX, you might also want to give a hand here. I would love to help with the issue of the SWT/GTK+ port being so damned slow, but I don't have sufficient time to spare to help out (I'm in my final year of uni and the exams are looming). As noted by Clemens, IBM don't seem to care a great deal about this issue at the moment so probably the only solution that we are likely to see will come from a community-led effort to solve the problem. My two cents on the issue is that we shouldn't be getting on the backs of the GTK+ developers over this problem; it seems more likely that the SWT/GTK+ port is completely abusing the API in some sense. As mentioned by Owen Taylor in response to the bug posted by Riyad Kalla, eclipse might be behaving badly by making repeated unnecessary calls to expensive GTK operations. If this is the case, some local optimizations within the SWT/GTK+ port might do a lot to alleviate the problem (caching results etc, I'm sure you all know solutions to these kinds of problems much better than I do). If this problem is still around when I've graduated this July, I'd definitely be interested in investigating the problem in a lot more depth if this has not already been done. It would be nice if there was a lot more visible work being done within IBM to tackle this problem though...
Clemens, I believe you are correct, I was just re-reading some of these posts to see if anything particularly informative had been posted that I missed, and I noticed that (almost) all of the replies from IBM employees were questions to the users about the performance, about benchmarks, or even about benchmarking/debugging Eclipse/GTK... it does seem that none of them use the Linux release. I'm curious if any of the developers from IBM/OTI that created the GTK port are even signed up on this bug. It seems to me that if I was the developer for those alternative platform ports, I would be constantly profiling Eclipse to figure out why it is so damn slow. There has got to be a good handful of developers that wrote the GTK/SWT library that HAVE debugging versions of GTK and Eclipse installed on their machine that they can throw OptimizeIT at and see what its doing... I suppose the level of inactivity on this bug is what bothers me the most; knowing that 3.0 has more than 1000 bugs open and targeted for its release in ~3 months, and seeing that this bug is a P4-Enhancement makes me think this in fact will not be addressed for 3.0. The weird part is that for the SWT subproject plan and for the top-level Eclipse 3.0 plan, this exact bug is listed as the highest priority for the next releases (M-releases I believe). If that is the case, can any of the IBM employees comment on the progress of this? I see that this bug is still assigned to "platform-swt-inbox" which I'm guessing was the original placeholder for SWT filed bugs, noting that this bug was filed almost a year ago and still nothing but talk on this thread... <sigh> Just to give IBM an understanding of the gravity of this bug, this bug report has gotten people talking about getting a SWT->Swing port complete just to run Eclipse faster; could anything be more ironic than that?
We are not ignoring this proposed plan item but are very busy with committed items. During the life time of the bug report, some Eclipse milestones (M6) have had peformance on all platforms. This has clouded some of the issues. Here is summary of what has happened so far: 1) We have determined that low level event loop processing and JNI calls on GTK are not the problem using C and Java versions of OptionPane. They draw the same. 2) We have identified string drawing and measuring as performance problems and optimized them somewhat. We have looked at other string drawing calls on GTK and decided that they cannot be used. A separate bugzilla report has been created for string drawing. Here it is: https://bugs.eclipse.org/bugs/show_bug.cgi?id=51693 3) We have attempted to compare the SWT example JavaViewer that colors text with the Eclipse text colorer to see whether scrolling and drawing was "fast enough" in SWT. The comparison was done on a 233Mhz. We need to do it again on a faster machine because the slowness of the machine itself is the limiting factor. 4) We have determined that chaning "a to a1" in StyledText.java is glacial. John, please enter a bugzilla report against "Platform/Text" so it can be tracked separately. Indicate that the problem is on GTK and that Windows is fast. The issue here is that Eclipse is relying on the Windows version of the method setRedraw() to throw away all of the individual drawing requests. This is interesting issue and needs to be followed up with them. It may be that they will not be able to rely on this behavior or that SWT can provide a partial implementation of setRedraw() to fix this particular problem. *************************** THAT'S IT ************************** If you want to be helpful, find an Eclipse performance scenario. Run it on exactly the same hardware under Windows and another platform. Report the problem, indicating the processor, operating system and memory.
A separate bug for the Java editor has been logged under https://bugs.eclipse. org/bugs/show_bug.cgi?id=52899.
Comment to post #144: > 4) [Replacing "a" with "a1" is slow] There is an old rule with X11 programs: It always pays to spend a lot of effort in *not* calling an X function. Example: When you need to clear the screen because of damage, it's faster to clear the whole screen rather than to call XFillRectangle() four times. When you need to draw strings, it helps a lot to collect all the redraw requests and if they exceed a certain limit, drop all of them and just redraw the whole screen with maybe a few cliprects installed. So for example the code which highlights a line should only draw the string once even if that means to run a lot of Java code to prevent calling XDrawString () twice.
Comment to #144: > We have looked at other string drawing calls on GTK > and decided that they cannot be used. Is this based on #136 from Felipe Heidrich who obviously didn't understand my suggestion? I suggested to implement GC.drawString and GC.stringExtent with direct Xft calls: XftDrawStringUtf8 and XftTextExtentsUtf8, but he has talking about cursor movements, word wrapping... As if he was thinking about StyledText. > The comparison was done on a 233Mhz. We need to do > it again on a faster machine because the slowness of > the machine itself is the limiting factor. Sorry. I can't do that. This 233 MHz dinosaur is all I got :-( Another suggestion: Implement a cache of pango layouts. Instead of using the same pango layout over and over again, for each GC.drawString and GC.stringExtent, it should be possible to build a cache of allready calculated pango layouts. When painting the content of an editor the same string is calculated/painted over and over again. If a cache was used the most used strings to display could be found in the cache and we could skip the calculation fase and just do the painting. Note: I just tried another editor written i C, that is using pango in almost the exact same way as eclipse, by laying out each line to display. And guess what: It's damned slow too. Try for yourself: http://gedit.sourceforge.net
I'm curious to know what it is that gedit and eclipse are doing to GTK that cause it to be so sluggish. Does anyone where run Ajunta? (that GTK JDevelop clone). I'm curious how that runs... if that is slow too.
Steen, (I think) you didn't understand my comment. Can the Xft calls be used with all the font types that Pango supports (Bitmap, Type1, TrueType, OpenType) ? I don't think so but I might be wrong. Does the Xft calls handle bidi text ? If I pass a text containing English and Arabic, will the Xft calls reordered and shaped it before drawing/measuring ? I really don't think so. I know for sure that Pango supports all that. However, you are welcome to prove me wrong, write a piece of code showing that Xft calls can do what we need, benchmark it too. Maybe your ideas of using Xft calls to speed things up should be suggested on a bug against pango performance in the gnome bugzilla.
Are any of the people here interested in helping Owen track down the problem with Pango via some sample C apps that can show major speed descrepencies? Bug is here: http://bugzilla.gnome.org/show_bug.cgi?id=129473 What I think might be what he is looking for, is the Benchmark2.java program that was posted, but port it to straight C/GTK and post it here for all of us to run (and on that bug) so we can post our findings. If it turns out that GTK's drawing time is hugely improved, then we can go back to trying to find where in SWT things are going bonkers. If we see that GTK performance still lags behind by a signifigant number, then we can post our findings to that bug and help Owen track down in Pango where the bottleneck is. Comments?
Re: #148 & #150 I doubt that a C version of the Benchmark2.java would be much faster. Usually, when you don't do any IO, Java is as fast as C. Calling stuff via JNI is not the limiting factor. String rendering on X was always a killer; if you can avoid drawing something by any means, then don't draw. The reason why "replace a by a1" is so slow is that Eclipse constantly redraws the screen. On Windows, it throws all those redraw requests away. I suggest a solution like this: Collect redraws/updates in the text component (for example, when you want to redraw a line, create small object saying "redraw this line"). The text component should be able to store 2-3 of these. If a fourth comes along, the text component should drop all requests and put a "full redraw" into the queue. The queue gets flushed when the code reaches the main loop again. Other components should work in a similar way. Also, if there is a parent component which has "full redraw", drop all rendering requests from child components. Also when the bug mentioned in comment #121 is fixed, most of the problems will go away.
>Note: I just tried another editor written i C, that is >using pango in almost the exact same way as eclipse, >by laying out each line to display. And guess what: >It's damned slow too. >Try for yourself: http://gedit.sourceforge.net Quite interesting. I clocked 44 seconds for "a" to "a1" replaceall in StyledText. This is horrendously slow compared with 0.2 second in KWrite. I will pass on this information under bug 52899
Aaron, The c-version of Benchmark is not for us, its for Owen to use as a guideline while he's optimizing.
Re 151: The operating systems already "queue up the damage" when things need to be redrawn. I suspect that we are forcing the screen to be updated (either Eclipse is doing this or SWT is doing this as part of scroll()). Under Windows, when setRedraw() is off, nothing happens. On platforms that don't have this capability, you see every draw. 1) Please move all discussion of "a to a1" to bug#52899. 2) Please move all discussion of "string drawing" to bug#51693. Thanks.
Created attachment 8174 [details] C version of Benchmark2.java. Compile with "make c" This is a C version of the relevant benchmarks from Benchmark2.java. It tests only drawText() but it's a compact test for this one and it shows how slow this method is.
I'm on a SuSE 9.0 box with NVIDIA GeForce 4 MX440, driver version 5336 (the newest one) and Linux 2.4.23. It's a dual 1GHz Pentium III with 1.5GB RAM. My timings are: Java results with FOX toolkit: gc.drawText 30753 gc.drawText 2 15400 gc.stringExtent 14851 gc.textExtent 13906 gc.fillGradientRectangle 12495 canvas.computeSize 1574 canvas.computeTrim 559 Java results with GTK toolkit: gc.drawText 35190 gc.drawText 2 16993 gc.stringExtent 154'533 !!! gc.textExtent 66'233 !!! gc.fillGradientRectangle 6615 (twice as fast) canvas.computeSize 35'282 !!! canvas.computeTrim 33'583 !!! C results gc.setLineWidth 420 gc.drawLine 6797 gc.drawText 11602 (1) gc.drawText 932'220 (2) Comments: (1) means: 1 million loops, using gdk_draw_text() (ie. no antialiasing, no clearing of the background, almost raw X11 speed. Can't get faster than that). (2) is the converted SWT function drawText(). The loop runs only 100'000 times which takes 90 seconds - which means there must be a bug lurking in there somewhere because the Java version is 100 times faster and is supposed to be the same code ;-) Maybe the guy who wrote the SWT code GC.java can have a quick look. The C code is only 238 lines, it should be easy to find the bug because I used the same names as the SWT code.
Aaron, thanks so much for doing this! I'll post it to gnome bugs ASAP.
Felipe, Xft is based on FreeType 2 which supports the following fonts by default: * TrueType fonts (and collections) * Type 1 fonts * CID-keyed Type 1 fonts * CFF fonts * OpenType fonts (both TrueType and CFF variants) * SFNT-based bitmap fonts * X11 PCF fonts * Windows FNT fonts * BDF fonts (including anti-aliased ones) * PFR fonts * Type42 fonts (limited support) You are probably right about the missing BIDI support, since I can't find any information about that. Does Motif support BIDI? I'm very busy at the moment but if I find the free time in a near future I'll try to implement the direct Xft calls so we can measure it.
Benchmark2.c uses gdk_draw_text() which is deprecated! We can not use this call in SWT cause it takes a GdkFont and all the widgets have PangoFonts. I believe PangoLayout is the right thing to use, if its not fast enough we should do what comment #150 suggested. If SWT is not using PangoLayout correctly, please let us (SWT developers) know. Answer to comment#147 (Another suggestion): Yes, SWT developers are considering the use of cache of PangoLayouts in StyledText (actually, StyledText would cache TextLayouts which is wrap to PangoLayout).
I've added the reply to comment #159 to bug 51693. Please continue the discussion there.
Here's a crazy thought for some of you infront of your machines to try: http://www.kde-look.org/content/show.php?content=9714 This is a new GTK theme engine that uses QT to do all the rendering... so far the feedback is really good. I wonder if someone wnats to install this and launch Eclipse and see what the performance is like?
Created attachment 8237 [details] GTK Theme Engine that uses QT to render the UI Attached for convenience. This is a GTK theme engine that has QT do the UI's rendering. If this runs Eclipse/GTK faster, maybe it might help us narrow down the problem. (or provide an alternative for people)
Riyad, I'm afraid that the QT based GTK engine doesn't help us much, cause what we are seing being slow is low level string drawing and mesuring methods (gc.drawString and gc. stringExtent). The native widgets like buttons, menus, trees, etc are already fast enough. Only custom drawn widgets that draws text (like styledText) are hit by our little performance problem. Or am I missing something?
Created attachment 8240 [details] SWT-Developers Sad but true
it seems to me that anjuta does not have these huge performance problems even when big files are displayed. it uses scintilla (http://cvs.sourceforge.net/viewcvs.py/scintilla) as editor widget. maybe someone can look at this one for some hints?
Did "replaceall a to a1" test using anjuta-1.0.0-119 on StyledText. It took about 48 seconds. This is slower than Eclipse on Windows with a processor half the speed of the test Linux box. Furthermore, Eclipse is running other tasks in the background. Worst of all, after finishing the replace task Anjuta is hanging with 40% User CPU. The Anjuta route does not look very promissing to me. We are replacing one problem with more problems.
John, bug #52899 is tracking the "change a to a1" problem in Eclipse. Please add your comments there. Thanks.
john, if i test using the scite editor (can be found on scintilla.org), which uses the same editor widget as anjuta the 11000 replacements take about 10 seconds! thats on an ibm thinkpad t21 (p3, 800mhz, fedora core 1 with most updates) if trying the scite editor configure your fonts to be antialiased: Options->Open User Options File This file should look like: font.base=font:!courier,size:10 font.small=font:!courier,size:9 font.comment=font:!courier,size:10 font.code.comment.box=$(font.comment) font.code.comment.line=$(font.comment) font.code.comment.doc=$(font.comment) font.text=font:!courier,size:10 font.text.comment=font:!courier,size:9 font.embedded.base=font:!courier,size:10 font.embedded.comment=font:!courier,size:10 font.monospace=font:!courier,size:10 font.vbs=font:!courier,size:10 i will post this comment on bug #52899 too.
Stefan, I repeated the ReplaceAll test with scite-1.50-27 editor. It took 6 seconds on SuSe Linux 8.2 with AMD 2000+ processor. Font settings in User Options did not make any difference. This is a lot faster than Anjuta and Eclipse on Windows. There must be something on Anjuta that makes Scite work slower.
I saw that bug 52899 was closed (the replace a with a1), what does that mean for this bug? Are our problems going to be solved, or are we still up molases creek without a paddle?
It means that we fixed a particular case. Comment #144 is the summary of this problem report and still holds true. Do you have an specific areas where we could do some work?
Steve, Thank you for the reply, actually my original reason for having interest in this bug wasn't so much the editor performance as it is the entire UI sluggishness under Linux. Somewhere along the road (in this bug) we all got sidetracked into specifically the text speed operations on Linux, and I think that somehow got funnelled into speeding up the editor; which is great, it just doesn't help the rest of the UI. A quick recap of what I mean: Pentium 4, 2.8Ghz, 1 Gig ram, GeForce 5200, 4496 Drivers, Gentoo Linux (Stable), KDE 3.1.5, GTK 2.2.4, Pango 1.2.5, XFree 4.3, Eclipse 2.1.3, JDK 1.4.2_04 On the machine above, it takes close to 1 full second for me to switch between perspectives on a fresh load of Eclipse. Obviously there is the initial load time of the objects, but if I flop back and forth between say the Java perscpective and the Debug one, it will take around 500-650ms... considering that on Windows it is an instantaneous switch of the screen with no noticable redraw (on a machine slower than this) AND almost the same on linux using the SwtFox plugin (uses the Fox API to do rendering), it makes me think something is going on in SWT. Note that GTK is not a fast API, I understand, but it certainly isn't that slow on Linux or I imagine the Gnome desktop users would have killed themselves already.
Riyad: Which theme are you using? Bluecurve perhaps?
Actually I'm just using a stock KDE desktop, Plastik on the window decorations and Alloy on the widgets. When someone made the comment that KDE themes made a different, I went nuts trying everything from Keramik to ThinKeramik to QT Windows and none of them made a difference. So to go to another extreme just to get Eclipse to perform better, I installed Gnome 2.4.2 and switched my desktop completely to a default Gnome install... again no difference at all.
Okay, I'm curious about the GTK theme you are using -- in particular the control/widget theme. This is not the KDE theme.
I agree. Lets find the place in the Eclipse source where the switching is done and simply measure it. I have no idea where that is and no idea where to start looking. Please FIND THAT PLACE and lets get some real numbers. Someone from Eclipse UI please help ... The erasing/redrawing on GTK is due to a combination of X and/or GTK filling the background for the X windows before painting. Windows uses the Control.setRedraw() API (which is not implemented on the other platforms) to simply throw away all draw requests. Bug #53791 was opened to track this issue but we are still working on it and have not updated the bug report (yet) with our findings.
Sorry Douglas I misunderstood, I'm not using any GTK theme that I'm aware of, whatever the default is. I've attaced a screenshot of the widgets from my screen so you can see it.
Created attachment 8924 [details] Screenshot of GTK theme (default) This is a screenshot of the top part of Eclipse (showing the GTK theme currently applied)
Reply to comment 176: > Windows uses the Control.setRedraw() API (which is not implemented on the other > platforms) to simply throw away all draw requests. As I said in bug 53791, AFAIU that API is called gdk_window_begin_paint_rect/region() on GTK+. It is documented at "http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#gdk-window-begin-paint-rect".
Implementing Control.setRedraw() with gdk_window_begin_paint_rect() does not help perspective switching at all. Please keep the discussion of the API to bug #53791. Thanks.
*** Bug 57657 has been marked as a duplicate of this bug. ***
To try and get a better idea of how much the Gtk+ theme affects performance, we investigated the performance of perspective switching with different themes. Test setup: I200405111600 P4 2.53 GHz 768M of memory RH9 kernel 2.4.20-30.9 and Gtk+ 2.2.1-4 We timed the performance of 100 switches between the resource and java perspectives with one editor open showing org.eclipse.ui.internal.util.Util. The event loop was allowed to spin to completion after each switch to allow repaints to occur. To be clear: for i in 1 to 100: switch to resource perspective handle events switch to java perspective handle events We ran our test once per theme and twice with the default Red Hat theme Bluecurve. Each theme below is included with RH9 with the exception of CleanIce, for which we used the CleanIce engine version 1.2.8. The theme was changed using the 'gnome-theme-manager' application. The results were as follows: Theme Elapsed Time Compared to Traditional ------------------------------------------------------- Traditional 3m23s 100.00 Simple 3m24s 100.49 High Contrast 3m25s 100.99 Mist 3m25s 100.99 CleanIce 3m26s 101.48 Crux 3m28s 102.46 Ocean Dream 3m31s 103.94 Grand Canyon 3m36s 106.40 SmokeyBlue 3m47s 111.82 Bluecurve (2) 4m32s 133.99 Bluecurve (1) 4m38s 136.95 We recommend avoiding Bluecurve. Switching from Traditional to BlueCurve shows roughly a 35% slowdown in this test.
Considering that RH9 reached its EOL in the 30th of April 2004, wouldn't it be more appropriate to execute these tests on a distribution that was released more recently? The best bet would probably be Fedora Core 1 (and maybe Fedora Core 2 after it's released on the 17th of May 2004). It might not make a difference, but perhaps the slowness, which BlueCurve has shown in the tests, has been addressed in these releases.
Avoiding Bluecurve?.. IMO the conclusion of your research actually is that the variety of GTK+ themes don't matter to the slowness of SWT/GTK. The speed difference between SWT/Motif and SWT/GTK doing this particular excersise at least visually seems > 100% while the numbers you provide are hardly above 30%.
Billy, please post your code so others can duplicate your results.
Billy, We really appreciate the effort and time you took to put this benchmark together. It atleast gives the devs (and us) something more solid to run with and optionally post OUR results as well. With more eyes (and computers) on this we might be able to drill down to the real cause of the problem <cough>GTK</cough> Who said that? :D
Created attachment 10560 [details] Perspective Switching Performance Test Here is the code we used to test performance differences across Gtk+ themes. It is meant to be applied to the org.eclipse.ui.tests project.
For comparison, we ran the tests with our same setup on Motif. Since the GNOME theme is also responsible for the window titles, which change during perspective switch, we tested with both the Traditional and Bluecurve GNOME themes. Theme Elapsed Time Compared to Traditional ------------------------------------------------------- Motif-Bluecurve 3m29s 102.96 Motif-Traditional 3m34s 105.42 We believe that the speed of perspective switching is not significantly different between Motif and Gtk+ (assuming you are not using Bluecurve). Note that this data is only relevant for perspective switching and does not necessarily map to other operations.
For comparison, we also ran this test on Windows. Test setup: I200405111600 P4 2.53 GHz 768M of memory Windows XP Pro, Service Pack 1 Elapsed time: 1m30s, compared to Gtk+-Traditional 44.28% Windows seems over twice as fast for this test. This seems to indicate that the windowing system has a significant component to perspective switching. Also, the tests on both platforms were tested using the Sun VM version 1.4.2, although the Linux version is 1.4.2_03-b02 while the Windows machine is using 1.4.2-b28.
As part of bug 58738, we have been investigating improvements in the performance of perspective switching. The amount of work we do during a perspective switch has gone down significantly in recent builds. This means that a higher percentage of the time in a perspective switch is devoted to actually rendering the widgets. Results comparing Bluecurve and CleanIce on I200405181200: Theme Elapsed Time Compared to CleanIce ------------------------------------------------- CleanIce 1m40s 100.00% Bluecurve 2m45s 164.71% Windows 51s 50.85% Motif 2m12s 131.51% The gap between a fast theme and Bluecurve is now much wider, with Bluecurve over 1.5 times slower than CleanIce. While we have significantly improved our performance, I think we are exposing a significant performance problem with Bluecurve in particular.
Billy, I just took some time to track the other bugs you have referenced and see that most (all?) of them have really been a success down the path of 'speeding stuff up'. Those numbers at the end of the Bug 58738 were very impressive! Do you and your team have a todo list for 3.0 relating to performance? If so would you mind sharing with us (or Bug #s) so we can keep up with the progress as well? Thanks again for the effort/work, we appreciate it.
Riyad, The performance related defects that are 3.0 candidates have the "performance" keyword and me on the CC list.
We are going to be updating the 3.0 plan to reflect that work has been done and we are going to declare "work completed" for 3.0. For the next release we will add this defect report to the plan to ensure that the focus on performance continues. Between now and when 3.0 ships we will continue to fix bugs, but only defects that have a target milestone of 3.0 RC<n> are planned to be addressed. If you are aware of other performance problems that have not been tagged please let us know. If the defect is serious and making the change isn't too risky we will try to get it in for 3.0 otherwise it will have to wait until the next release.
Please check bug#65269. The fix for this bug improves drawing performance quite a bit. It did not go into RC2, because it had outstanding issues. These should be addressed in the patch. Please get the patch, try it out and report if you see any painting problems (in bug#65269). We want to release the fix for RC3, but we will not release it unless it is well tested.
As you can see others are also hurt by the lack of speed in pango: http://www.osnews.com/comment.php?news_id=7953
Has the Eclipse team determine that they have done all the enhancements to the SWT/Eclipse platform that they can, and the rest is on the shoulders of the GTK (Owen's) developers? I ask because in the wake of this report it seems like that SWT team made some major enhancements (8 bugs or so just related to performance) and don't know if there was anything else on the radar to be done for 3.1 or 3.x. Could the devs fill us in? We haven't lost interest in performance :P
Me, lost interest in performance? You've got to be kidding. We made a bunch of improvements for 3.0, mostly working around low level problems/features in GTK. On the Mac (and every other platform for that matter), we improved the performance of tables and trees, specifically in the area of adding items. We implemented the SWT.VIRTUAL style for tables to allow lazy loading. Unfortunately, this was added to late in the cycle for Eclipse to make use of it. At any rate, each individual issue was captured by a separate bug report, resolved and closed. As Kevin Haaland indicated, work on this bug report was completed for 3.0. It doesn't mean that we have lost our focus on performance. Please continue to identify scenarios and we will address them. Thanks. Actually, special thanks to Andrea Aime and Billy Bigs for their work in this area.
Steve, It seems you read my post and interpreted it as offensively as possible... it was actually intended to be a compliment and a "Thank you" to the SWT team for their hardwork and relief that the performance problem in GTK was publically identified so the SWT team didn't have to keep chasing around looking for why Eclipse-GTK was still performing subpar after all those major fixes/boosts you guys integrated before 3.0. Then that was followed up with a "So whats left to do?" question, because I was well, honestly interested in whats left on the radar for you guys to do.
No offense was taken, in the slightest. Hey, I wasn't even offended by the guy who posted the camel jpg. Right now, we are in the planning phase for 3.1 but we are always on the look out for ways we can make SWT faster. Keep on submitting those scenarios and entering problem reports.
This is no longer a plan item but ongoing maintenance. Please enter individual bug reports for any outstanding issues. Leaving this bug report open because it contains useful information.
First of all: If you want to have the performance-issues fixed, vote for: 39446 and have a look at http://swtfox.sf.net It seems performance of GTK2 port can't be tuned withought rewriting large parts. However I tested SWTFOX some time ago and it was really fine! It looked and felt as nearly good as GTK2 but its speed was as good as win32's, even outperforming Motif! Since it was statically linked no extra dependencies were introduced, the only problem is that it is still very unstable and not 100% feature complete. However it managed to run Eclipse-2.1 and I think 3.0 is also fine! I do not understand why the motif-port wont be dropped (it is nearly unuseable from the users point of view), and replaced with the SWTFOX-Toolkit! Please, please make SWT-Fox an official port! There is already a bug-report about this, if you want faster Eclipse go any vote here: 39446 The motto of swt-fox is: "if you see any performance, inferior to SWT/Windows, you should report it as a bug". Please vote, thanks, lg Clemens Last but not least some user experience: I downloaded 3.1RC and it a real pain! On my P4-2.6Ghz (with 2D-accerlated NVidia-driver) a perspective-switch takes 3s (painting only, perspective loaded) and repositioning a splitpane is nearly a joke :-(
I recently upgraded til Fedora core 3, which includes xorgs 6.8, and I noticed an improvement in performance. I'm using the Composite extensions in xorgs, which might have something to do with it. It still takes a long while to switch perspectives, but the package explorer seems more snappy when collapsing and expanding the tree. Also the splitpane seems faster. It's still WAY slower than eclipse on windows, but it's nice to see some improvement. Also, if you have multiple displays and a nvidia card, I recommed staying away from the xinerama-mode as it is significantly slower than letting X11 think there's only one display and letting nvidia's driver split the picture.
Should this one still be open?
Performance with Eclipse 3.2RC7 and SuSE Linux 10.1 (gtk 2.8.10, pango 1.10.2) is fine.
+1 I think we should close this bug. It dates back to 2003 and lots of work has been done since then. If you read the bug report, most interesting work was broken out, tracked and fixed elsewhere. I suggest we do that with any outstanding specific issues people are having and close this sucker!
+1 I don't know who can vote for this, but I agree with you Steve. I don't think this bug report can do much more since most of these issues have been addressed. We should aim for more detailed bug reports opened against specific components. Having said that, there still are several “Platform specific performance problems” with SWT such as Bug#134760 and Bug#51693 (among others). I trust that by closing this bug (and the almost 100 votes) the more specific bug reports (with less followers and fewer votes) won't be ignored. Cheers, Ian
Absolutely not. In fact, these other reports can actually be closed because they are concrete. Everyone, all million of you, speak up. Enter specific bug reports for the issues you are seeing. I'm going to close this bug report.
I'm not a committer, but being "one of the millions": +1 from me too. **This bug is gust too generic to remain open.** I'm all for fixing https://bugs.eclipse.org/bugs/show_bug.cgi?id=51693. This is what hurts me really: the abusmal performance of StyledText and my custom Grid control due to slow text drawing. If I switch off the calls to GC.drawString() my Grid flies. In fact, comment #7 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=37683#c7) pretty much says it all for me. Now, whether fixing this within SWT is possible - I don't know - it could be that Pango & XRENDER can just do so much.
I'm asking for votes from everyone. If I don't get any, I'm closing it. (I'm like an angry wife, threatening to walk out the door ... I'm putting in my coat, I'm really leaving ...)
You'll be back *flips the game back on*
+1 for closing it Too much old info in this bug. Someone will eventually create a new generic perf problems bug and it will be clean for a day or two. Might want to consider creating a generic perf problem bug for each version (ie. Make a 3.3 one now, then when 3.3 is released, make a 3.4 one, etc).
+1 for closing it
After thinking long and hard, I'm closing this bug as INVALID. The choices were FIXED, WONTFIX, LATER, REMIND and WORKSFORME. Certainly FIXED and WONTFIX are bad. Some people are still having problems and telling them they don't or that they are fixed isn't right. LATER and REMIND aren't right either. I was tempted by WORKSFORME because I never really had any of the problems that others had, but that's just as bad as FIXED or WONTFIX. That leaves INVALID, which is probably how the bug should have been dealt with in the first place. A bug report that is this open ended can never be closed. So, enter those specific bug reports for problems you are seeing and let's put this one to rest.
