Comment 1 Linuxhippy 2016-05-15 15:43:49 EDT

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)

Comment 2 Linuxhippy 2016-05-16 05:40:22 EDT

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)

Comment 3 Eric Williams 2016-05-16 08:25:48 EDT

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.

Comment 4 Linuxhippy 2016-05-16 08:39:50 EDT

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)

Comment 5 Leo Ufimtsev 2016-06-10 18:06:38 EDT

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.

Comment 6 Linuxhippy 2016-10-09 11:39:36 EDT

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>

Comment 7 Eric Williams 2016-10-09 11:46:10 EDT

(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.

Comment 8 Linuxhippy 2017-01-30 11:41:07 EST

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.

Comment 9 Andrey Loskutov 2017-01-31 01:28:02 EST

Which GTK3 version do you test btw?

Comment 10 Andrey Loskutov 2017-03-24 06:47:12 EDT

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.

Comment 11 Linuxhippy 2017-03-25 04:25:15 EDT

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.

Comment 12 Alexander Kurtakov 2017-03-25 05:18:47 EDT

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.

Comment 13 Leo Ufimtsev 2017-03-27 10:05:47 EDT

(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.

Comment 14 Leo Ufimtsev 2017-07-21 11:13:34 EDT

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.

Comment 15 Patrick Tasse 2017-07-21 11:37:32 EDT

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.

Comment 16 Linuxhippy 2017-08-27 16:04:32 EDT

> 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?