Community
Participate
Working Groups
Created attachment 261750 [details] benchmark Because running Eclipse with SWT on top of GTK3 felt significantly slower than the GTK2 version (SWT_GTK3=0), I tried to find some way to measure the performance degradation. I remembered the MigLayout (GUI layout library which supports SWT, Swing and JavaFX) benchmark application which is the only application to test *real world* behaviour instead of benchmarking dumb primitive drawing operations. The test was conducted on Fedora-24 beta, GTK3 and GTK2 were running with default/stock themes and with hw-accelerated intel driver (SNA): Time per benchmark run: GTK3: 1942 millis GTK2: 757 millis Motif: 615 millis (32-bit VM, SWT-3.5.2) Swing: 156 millis (default Ocean LnF) So running in GTK3-mode means ~2.5x lower performance than GTK2. Worse, Swing performs over 12x as good as SWT-GTK3 for this test case. It is quite frustrating to see UI performance of Eclipse degrating like this. Options used: GTK: java -cp swtdemoappbase.jar:/usr/lib64/eclipse/swt.jar:swtdemoapp.jar net.miginfocom.demo.SwtDemo -bench100 Motif: java -server -cp swtdemoappbase.jar:swtdemoapp.jar:swt.jar net.miginfocom.demo.SwtDemo -bench100 Swing: java -cp /usr/lib64/eclipse/swt.jar:swingdemoapp.jar net.miginfocom.demo.SwingDemo -bench100
Some further numbers of the same machine running Windows7 (64-bit java, tired-compilation): Swing: 262ms (Windows LnF) SWT: 852ms (Windows7, "classic" theme) SWT: 1026ms (Windows7, Aero)
Out of curiosity, I also tested the unofficial SWT port for the fox-toolkit (SWT-3.0 from 2004), it is indeed the best-performing SWT implementation so far. So all results combined look like: Linux: GTK3: 1942 millis GTK2: 757 millis Motif: 615 millis (32-bit VM, SWT-3.5.2) Fox: 375 millis (32-bit VM, SWT-3.0, unofficial fox port) Swing: 156 millis (default Ocean LnF) Windows: Swing: 190ms (Ocean LnF) Swing: 262ms (Windows LnF) SWT: 852ms (Windows7, "classic" theme) SWT: 1026ms (Windows7, Aero)
What version of Eclipse/SWT are you using to test? Anything older than the most recent Neon milestone won't perform as well on GTK3 as some performance fixes have gone in in the last ~2 months.
Indeed, the tests I conducted used the swt version bundled with Fedora24. When using the latest SWT build from eclipse neon (RC1), results are a tiny bit better GTK3: 1901 millis (SWT 4.6rc1)
Interesting observation. I'm not sure why thou. I sort of wonder if it's because Gtk3 itself is slower, or because of the way SWT uses Gtk3 that makes eclipse slower. If someone has time to benchmark Gtk2 vs Gtk3 or has some knowledge about their performance differences, then let us know.
And yet another performance report (even with an easy way to reproduce - most other UI performance reports are mostly about perceived performance) rotting away. <irony mode> No wonder Eclipse has the repotation of being slow and bloatet - perhaps it is the result of neglecting the importance of profiling and optimization after new features have been introduced. It seems the GTK3 port was made default without anybody running any kind of benchmark on it. </irony mode>
(In reply to Linuxhippy from comment #6) > And yet another performance report (even with an easy way to reproduce - > most other UI performance reports are mostly about perceived performance) > rotting away. > > <irony mode> > No wonder Eclipse has the repotation of being slow and bloatet - perhaps it > is the result of neglecting the importance of profiling and optimization > after new features have been introduced. It seems the GTK3 port was made > default without anybody running any kind of benchmark on it. > </irony mode> With SWT having the amount of manpower it does, patches from the community are always welcome.
Out of curiosity, I benchmarked the windows version of swt running under wine: 2380 millis. So despite lots and lots of IPC and context-switches between the wineserver and the benchmark-process, SWT for win32 ran almost as fast under wine as the native SWT/GTK3 port.
Which GTK3 version do you test btw?
Just few more observations: we recently switched from 3.8.2 to 4.6.3 in the lab and ALL engineers I've talked about their issues with new version were mentioned that the new Eclipse feels slower then before. Switching editors, opening menus, dialogs, switching between windows - there are delays we've never seen before. Sure, this is partly due e4 changes, but I also "feel" the slowness compared with my windows laptop, which is by far inferior in the specs (i3 2 cores with 8GB RAM) compared with my Linux workstation (some xeon 8 cores and 32 GB RAM). Please notice, that we disable "e4 Themes" by default, so we run "bare" SWT on GTK3. We are on RHEL 7.2, gtk3-3.14.13-16.el7.x86_64.
Andrey: There is still the possibility to use the GTK2-version of SWT by setting the environment-variable SWT_GTK3=0 I use it on a daily basis as otherwise Eclipse inside VirtualBox is unbearable sluggish.
Leo, would you please investigate this one. I propose starting small e.g. by Test_org_eclipse_swt_widgets_Shell with GTK2 (2.24) -> ~1 sec with GTK3 (3.22) -> ~1.8 sec on my machine. This should help finding out where the additional time is lost.
(In reply to Alexander Kurtakov from comment #12) > Leo, would you please investigate this one. > I propose starting small e.g. by Test_org_eclipse_swt_widgets_Shell > with GTK2 (2.24) -> ~1 sec > with GTK3 (3.22) -> ~1.8 sec > on my machine. This should help finding out where the additional time is > lost. Added to my todo list.
Performance regression is seen in SWT Bot tests. Gtk2: 15 mins. Gtk3: 2-3 hours. Bug 506807 – SWTBot's tests take a very long time to execute in GTK3 https://bugs.eclipse.org/bugs/show_bug.cgi?id=506807 Thought: SWTBot could be used as a benchmark when diagnosing the issue. It seems that there's some unnecessary sleep in event execution logic. They report that as an example SWTBotPopupMenuTest takes 7 seconds on Gtk2, but 25 seconds on Gtk3.
In the SWTBot test suite, we create a new Display instance and dispose it between every @Test method. What we had observed is that when disposing the display between tests, the Java stack showed the VM in org.eclipse.swt.internal.gtk.OS._gtk_widget_destroy(Native Method) for a long time. At the beginning of the tests suite it was normal, but it kept getting progressively slower as more tests were executed. By the end of the test suite, it could take more than a minute to dispose the display between tests.
> At the beginning of the tests suite it was normal, but it kept getting > progressively slower as more tests were executed. By the end of the test suite, > it could take more than a minute to dispose the display between tests. Was the root-cause ever investigated, or only worked-around? Has it been reported to GTK+ developers at least?
I've tried the benchmark app with today's swt.jar 4.9 I-build on Fedora 28 . GTK3 (3.22.30): Java Version: 1.8.0_172 Time to Show: 468 millis. Benchmark Run Time: 142261 millis. Average Run Time: 1422 millis (100 runs). GTK2 (2.24.32): Java Version: 1.8.0_172 Time to Show: 323 millis. Benchmark Run Time: 171047 millis. Average Run Time: 1710 millis (100 runs). Can someone else please check whether he sees GTK3 being still slower than GTK2?
@Patrick Tasse, did the SWTBot situation improve? If I remember correctly, the performance was unbearable. Perhaps bug 506807 could be updated?
I've recently updated WireframeSketcher RCP app to Eclipse 4.8 and switched from GTK2 to GTK3 on Linux. Now I am receiving complaints from users about the slowdown of the application. Redraws are much slower now. Using SWG_GTK3=0 option solves the problem instantly for them. Note that WireframeSketcher is using GEF/Draw2d which draws directly on GC. I am now considering switching back to GTK2 permanently. GTK3 has better support for HiDPI, but if the slowdown is the price to pay then this is not acceptable. But since the support for GTK2 is being dropped, it's a bad option too. So something must be done to improve the speed on GTK3. I'll try to investigate the issue more and see if I can profile it myself to find exactly where the slowdown occurs. Any suggestions are welcome.
(In reply to Peter Severin from comment #19) > I've recently updated WireframeSketcher RCP app to Eclipse 4.8 and switched > from GTK2 to GTK3 on Linux. Now I am receiving complaints from users about > the slowdown of the application. Redraws are much slower now. Using > SWG_GTK3=0 option solves the problem instantly for them. > > Note that WireframeSketcher is using GEF/Draw2d which draws directly on GC. > I am now considering switching back to GTK2 permanently. GTK3 has better > support for HiDPI, but if the slowdown is the price to pay then this is not > acceptable. But since the support for GTK2 is being dropped, it's a bad > option too. So something must be done to improve the speed on GTK3. > > I'll try to investigate the issue more and see if I can profile it myself to > find exactly where the slowdown occurs. Any suggestions are welcome. Do you experience this with 4.9? There have been a number of speed improvements in this release.
Alexander, yes, I actually do. I've stated incorrectly in my previous comment that I've updated WireframeSketcher to Eclipse 4.8. It's actually Eclipse 4.9, so yes, the slowdown problem is being experienced with the latest version.
(In reply to Peter Severin from comment #21) > Alexander, yes, I actually do. I've stated incorrectly in my previous > comment that I've updated WireframeSketcher to Eclipse 4.8. It's actually > Eclipse 4.9, so yes, the slowdown problem is being experienced with the > latest version. Cna you come up with good reproducible case showing the slowdown (preferably in pure SWT) also knowing the details like distro used, gtk version and etc. would be helpful. Such slowdowns can be caused by old gtk version or by gtk module some of the distros ship and etc.
Created attachment 276504 [details] Clipping performance test Alexander, I've finally tracked down the issue and in my case it comes down to the performance of the GC#setClipping method in the situation when GC has a Transform set on it. Following down this path the slowdown is caused by the call to limitClipping in setCairoClip method: /* * Bug 531667: widgets paint over other widgets * * The Cairo handle is shared by all widgets, but GC.setClipping allows global clipping changes. * So we intersect whatever the client sets with the initial GC clipping. */ if (GTK.GTK_VERSION >= OS.VERSION(3, 14, 0) && OS.CAIRO_CONTEXT_REUSE) { limitClipping(clipRgnCopy); } As it can be seen, the issue is caused by the fix for Bug 531667, which I've had problems with before. Using the -Dorg.eclipse.swt.internal.gtk.cairoContextReuse=false kill switch makes the problem go away. Unfortunately this option is not enabled by default, and I cannot force its use when WireframeSketcher is installed as a plugin into an existing Eclipse. I also don't know what other side effects this option can have. I've attached a performance test that shows the problem with pure SWT. Run it with and without SWG_GTK3=0 to see the performance difference. Please let me know if you need more information. This bug is critical for me and I'd like to see a fix as soon as possible.
Hi Peter Severin, can you open a new ticket that indicates the regression from bug 531667? Re-using this one is probably not a good idea. Best regards, Simeon
Simeon, I've created Bug 540908. Not sure how to mark it as regression from bug 531667.
Created attachment 276514 [details] GC#drawPath performance test After disabling the cairoContextReuse flag the renderering performance for WireframeSketcher is still visibly slower on GTK3 than on GTK2. After looking into this issue I am narrowing it down to GC#drawPath method. I am not sure what the difference is as on both GTK2 and GTK3 this results into a native call to cairo_stroke. I've created a SWT snippet that measures the performance difference. On my machine the time on GTK2 is 2468ms and 55424ms on GTK3. I'd appreciate any help with this.
(In reply to Peter Severin from comment #26) > Created attachment 276514 [details] > GC#drawPath performance test > > After disabling the cairoContextReuse flag the renderering performance for > WireframeSketcher is still visibly slower on GTK3 than on GTK2. After > looking into this issue I am narrowing it down to GC#drawPath method. I am > not sure what the difference is as on both GTK2 and GTK3 this results into a > native call to cairo_stroke. I've created a SWT snippet that measures the > performance difference. On my machine the time on GTK2 is 2468ms and 55424ms > on GTK3. > > I'd appreciate any help with this. Are you running on X11 by any chance? I am getting huge times (60000 ms+) for both GTK3 and GTK2 on X11.
(In reply to Eric Williams from comment #27) > (In reply to Peter Severin from comment #26) > > Created attachment 276514 [details] > > GC#drawPath performance test > > > > After disabling the cairoContextReuse flag the renderering performance for > > WireframeSketcher is still visibly slower on GTK3 than on GTK2. After > > looking into this issue I am narrowing it down to GC#drawPath method. I am > > not sure what the difference is as on both GTK2 and GTK3 this results into a > > native call to cairo_stroke. I've created a SWT snippet that measures the > > performance difference. On my machine the time on GTK2 is 2468ms and 55424ms > > on GTK3. > > > > I'd appreciate any help with this. > > Are you running on X11 by any chance? I am getting huge times (60000 ms+) > for both GTK3 and GTK2 on X11. I tried GTK2 with 4.7.3 and I can reproduce your times of ~2500ms. GTK3 on 4.7.3 with X11 takes around 65000ms, but GTK3 on Wayland for 4.7.3 and master take ~5500ms. I'm not quite sure why this is, seems like Cairo drawing on GTK3 with X11 has some major performance hit, but I am not sure why. I'll continue to investigate.
(In reply to Eric Williams from comment #27) > (In reply to Peter Severin from comment #26) > > Created attachment 276514 [details] > > GC#drawPath performance test > > > > After disabling the cairoContextReuse flag the renderering performance for > > WireframeSketcher is still visibly slower on GTK3 than on GTK2. After > > looking into this issue I am narrowing it down to GC#drawPath method. I am > > not sure what the difference is as on both GTK2 and GTK3 this results into a > > native call to cairo_stroke. I've created a SWT snippet that measures the > > performance difference. On my machine the time on GTK2 is 2468ms and 55424ms > > on GTK3. > > > > I'd appreciate any help with this. > > Are you running on X11 by any chance? I am getting huge times (60000 ms+) > for both GTK3 and GTK2 on X11. Hi Eric, please take a look at bug 540908. I believe Peter's problem was mostly solved there. Best regards, Simeon
(In reply to Simeon Andreev from comment #29) > (In reply to Eric Williams from comment #27) > > (In reply to Peter Severin from comment #26) > > > Created attachment 276514 [details] > > > GC#drawPath performance test > > > > > > After disabling the cairoContextReuse flag the renderering performance for > > > WireframeSketcher is still visibly slower on GTK3 than on GTK2. After > > > looking into this issue I am narrowing it down to GC#drawPath method. I am > > > not sure what the difference is as on both GTK2 and GTK3 this results into a > > > native call to cairo_stroke. I've created a SWT snippet that measures the > > > performance difference. On my machine the time on GTK2 is 2468ms and 55424ms > > > on GTK3. > > > > > > I'd appreciate any help with this. > > > > Are you running on X11 by any chance? I am getting huge times (60000 ms+) > > for both GTK3 and GTK2 on X11. > > Hi Eric, > > please take a look at bug 540908. I believe Peter's problem was mostly > solved there. > > Best regards, > Simeon Yes I believe you are correct. Peter if you can confirm this is no longer an issue for you then I'll close this ticket.
Yes, the biggest cause of bad performance was bug 540908. I still feel that GTK3 is slower than GTK2, but the differences are less obvious now.
(In reply to Peter Severin from comment #31) > Yes, the biggest cause of bad performance was bug 540908. I still feel that > GTK3 is slower than GTK2, but the differences are less obvious now. GTK3 has more overhead than GTK2 in general, and I think some of this is seen on the drawing side since GTK3 uses Cairo. If there are any significant performance issues or regressions, please file another ticket -- I am going to close this one.
