Community
Participate
Working Groups
With the attached sample setting 169 items to the read-only combobox on SWT 4.614 takes around 10s on my Ubuntu 14.04 (and Ubuntu 15.10, too) causing the window to turn dark.
Created attachment 260308 [details] Sample code
On fedora 23 I am getting a time of 1.4 seconds with I20160314-2000.
Can you please check this again with the latest build?
I've tried with 4.615 and this is MUCH snappier. It took only ~100ms.
Sorry, it looks like I've tried the wrong jars. Now I'm getting ~8s for 169 items again (with the latest 4.615 jars).
The fast time was with SWT_GTK3=0.
Were you able to reproduce the delay? I've tried the v4621 and it still is there.
I can't reproduce this bug on Eclipse Neon, SWT master, Fedora 24 with GTK3.20. GTK2 insert time is ~21ms, GTK3 insert time is ~820 ms.
I'm getting these times on Ubuntu 14.04. $ gnome-session --version gnome-session 3.9.90
After having upgraded to Ubuntu 16.04 (Gnome 3.18) it is faster, but still takes 4100ms.
After updating Gnome to versiion 3.20 I'm getting now ~3700ms. Not that quick for only 171 items. I expect it to be below 100ms.
Downgrading severity since this is a performance issue. Also this seems CPU dependent. At home (AMD FX-8120) I am getting ~2000ms. At work (Intel Core i5 4300) the time was 820ms. No doubt GTK3 takes longer -- but the difference in the two times varies greatly depending on what CPU you have.
My tests were done on Core i5 machines.
A have the same issue with Combo on Linux Mint 18. Adding 1500 items tooks about 1-2 minutes on i5 cpu. A've tried setItems with no difference in performance. This bug must have top priority to fix.
Forgot to say swt 4.6.1 linux x64
Increased the importance because this is a massive performance problem that prevents using GTK3 for real-world products.
My results as of this morning: Intel® Core™ i7-6820HQ CPU @ 2.70GHz SWT master Fedora 27 GTK3.22.26 First run: ~800ms Every run thereafter: ~1100ms While GTK3 is slower than GTK2, I cannot reproduce the ~4000ms times. Please try a latest I-build on the latest Ubuntu. Maybe also try Unity vs. GNOME? Any data will help us narrow down the issue.
Eric, we can't expect the end-users to upgrade their machines to make our application open dialogs in <1s instead of 10s - both is slow. I'm just a Java developer - is there some GTK developer here that can verify whether this is an inherent problem of GTK3? Then it might be useful to replace the (SWT) combobox with something else, e.g. an ordinary button with a popup menu.
(In reply to Thomas Singer from comment #18) > Eric, we can't expect the end-users to upgrade their machines to make our > application open dialogs in <1s instead of 10s - both is slow. I am not suggesting that. But so far no one on Fedora with basic GTK and GNOME can reproduce the issues -- this is why I am asking for someone with a modern Ubuntu to test on Unity and GNOME. The more information we have, the less time it will take us to reproduce the issue and fix the bug. > I'm just a Java developer - is there some GTK developer here that can verify > whether this is an inherent problem of GTK3? Then it might be useful to > replace the (SWT) combobox with something else, e.g. an ordinary button with > a popup menu. Yes, next step would be to write a native snippet and see if the issue is reproducible.
I've tried to open the preferences dialog in SmartSynchronize 3.4.12 (which contains 2 text encoding checkboxes) on my older Linux Notebook with Core i5 M460 @2.56GHz running Linux Mint 18.1 Serena, GTK 3.18.9 with Mint-X theme. With SWT_GTK3=1 it took ~12.6 seconds with the latest 4.830 SWT build from the master (2c1e42de2410e9ec). Even worse, it crashed with a NoSuchMethodError when trying to close the dialog, but this seems to be a different bug. With SWT_GTK3=0 it took ~2.5 seconds and did not crash.
(In reply to Thomas Singer from comment #20) > contains 2 text encoding checkboxes) not checkboxes - comboboxes.
Linux Mint KDE 18.2 x64 GTK2 version 2.24.30 GTK3 version 3.18.9 SWT build I20171121-0020 Adding 500 items takes 91ms for GTK2, 11079ms for GTK3. Performance degrades non-linearly, feels like O(x^2) or something. As a more "real-world" example, filling 2 combos with Charset.availableCharsets() and TimeZone.getAvailableIDs() respectively takes 26+128ms on GTK2, 1251+17430ms on GTK3.
I've played around with a native snippet, and it looks like the issue is not present in native GTK (my GTK3 snippet runs in ~33ms). Leo (most likely) will look into this bug after the webkit2 port is done.
(In reply to Eric Williams from comment #23) > I've played around with a native snippet, and it looks like the issue is not > present in native GTK (my GTK3 snippet runs in ~33ms). Leo (most likely) > will look into this bug after the webkit2 port is done. Thanks for looking into this. Btw, if you still have the native snippet, it would be useful to have it around somewhere. Would you be able to attach it here or submit it into the gtk native snippet test folder? (Probably push directly to master to avoid too much noise). Thanks.
(In reply to Eric Williams from comment #23) > I've played around with a native snippet, and it looks like the issue is not > present in native GTK (my GTK3 snippet runs in ~33ms). Leo (most likely) > will look into this bug after the webkit2 port is done. /Leo is finished with webkit2 port and is pulling out his bug spray.
~Status update. I did a code coverage. When we call 'GTK.gtk_combo_box_text_insert (handle, i, null, buffer);', there are no signals being processed by SWT until the call is completed. (neither gtk2 or gtk3). I.e, the delay is internal to Gtk3. I will need to figure out what's happening inside Gtk3 to figure out the delay. As reported earlier, the insertion time gradually increases with number of items. Time per insert: insert 10 = 1 ms insert 100 = 6ms insert 500 = 28ms insert 1000 = 62ms
The root cause seems to be that setting wrap_width via: GTK.gtk_combo_box_set_wrap_width(handle, 1); Makes gtk re-compute the drop-down list size after every single insert. Not setting this fixes the performance issue. I'm looking into a way to fix/work around this.
*** Bug 487271 has been marked as a duplicate of this bug. ***
(In reply to Leo Ufimtsev from comment #28) > The root cause seems to be that setting wrap_width via: > GTK.gtk_combo_box_set_wrap_width(handle, 1); > Makes gtk re-compute the drop-down list size after every single insert. > Not setting this fixes the performance issue. I wrote a fix: https://git.eclipse.org/r/#/c/123552/ Which basically disables wrap during active insertions and enables it lazily whn actually needed. Before: 200 items took 1000ms. Now : 200 items took 10ms Gtk3 (23 ms on Gtk2 for comparison). As per discussion with Alex.K, this is for 4.9 and at the moment will not be back ported to RC3 as the code is somewhat frozen. ~Awaiting review and merge.
Sravan, should we consider this one for RC3 ?
Running the bug snippet "Bug489640_ComboPerformanceTest", here are the before/after numbers with this patch: BEFORE: Setting widget.combo with 171 items took 863 ms. Setting widget.combo with 171 items took 1318 ms. Setting widget.combo with 171 items took 1136 ms. Setting widget.combo with 171 items took 1112 ms. AFTER: Setting widget.combo with 171 items took 23 ms. Setting widget.combo with 171 items took 415 ms. Setting widget.combo with 171 items took 407 ms. Setting widget.combo with 171 items took 418 ms. Note that the subsequent additions (after the first insertion) take longer because all the items are removed and then added again. IMO this is a pretty significant fix, and should be included in RC3.
(In reply to Eric Williams from comment #32) > AFTER: > > Setting widget.combo with 171 items > took 23 ms. > Setting widget.combo with 171 items > took 415 ms. > Setting widget.combo with 171 items > took 407 ms. > Setting widget.combo with 171 items > took 418 ms. I noticed that the same problem was present when removing a lot of items. I fixed this issue in patchset 4. Now adding & re-adding items takes +-20ms on every run.
(In reply to Alexander Kurtakov from comment #31) > Sravan, should we consider this one for RC3 ? Since it is not a regression I think we should target 4.9. Also I feel the code changes are non trivial. Better not to push in 4.8
(In reply to Sravan Kumar Lakkimsetti from comment #34) > (In reply to Alexander Kurtakov from comment #31) > > Sravan, should we consider this one for RC3 ? > > Since it is not a regression I think we should target 4.9. Also I feel the > code changes are non trivial. Better not to push in 4.8 That's a fair point. The patch ended up being somewhat bigger than initially anticipated. Closing for now. @Thomas Singer, if you could verify with latest nightly or maybe in a few weeks, that'd be great.
Perfect! With the latest build the times to add 171 items to the combobox was reduced from ~1.5s to ~30ms on my system, to replace the 171 items from ~2.2s to ~40ms.
(In reply to Thomas Singer from comment #36) > Perfect! With the latest build the times to add 171 items to the combobox > was reduced from ~1.5s to ~30ms on my system, to replace the 171 items from > ~2.2s to ~40ms. Thank you for verifying! I wonder if we have a simila issue with Tree's: 397042 – (TreeAddingNodesSlow) Adding tree nodes has N^2 complexity with respect to the number of children on GTK https://bugs.eclipse.org/bugs/show_bug.cgi?id=397042 We should investigate.
*** Bug 536905 has been marked as a duplicate of this bug. ***
*** Bug 540805 has been marked as a duplicate of this bug. ***
