After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 153605 - Performance problem in GtkComboBoxEntry and GtkCombo
Performance problem in GtkComboBoxEntry and GtkCombo
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkComboBox
3.16.x
Other All
: Normal normal
: Medium fix
Assigned To: gtk-bugs
gtk-bugs
: 592051 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-09-24 02:22 UTC by Billy Biggs
Modified: 2018-03-23 18:39 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test applications (8.17 KB, application/x-tar)
2004-09-24 02:23 UTC, Billy Biggs
  Details
testcase (2.51 KB, text/x-python)
2009-09-01 14:24 UTC, logari81
  Details
the patch (1.54 KB, patch)
2010-10-02 12:46 UTC, Benjamin Berg
none Details | Review

Description Billy Biggs 2004-09-24 02:22:51 UTC
Test case: a combo box of 10000 entries.  GtkComboBoxEntry is twice as slow as
GtkCombo, which is quite slow already.  On my machine (P3-733 with GTK+ 2.4.9):

  Using GtkComboBoxEntry...
  Adding 10000 entries took         372357 usec   ( 0.37 seconds).
  Realize widget took              7062282 usec   ( 7.06 seconds).

  Using GtkCombo...
  Adding 10000 entries took        3629198 usec   ( 3.63 seconds).
  Realize widget took                 3664 usec   ( 0.00 seconds).

This came out of this SWT bug:
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=74824

The application had a combo box which was fed dynamically generated content.
Comment 1 Billy Biggs 2004-09-24 02:23:32 UTC
Created attachment 31888 [details]
Test applications
Comment 2 Billy Biggs 2004-09-24 02:26:28 UTC
Increasing the number of entries shows that things get even worse:

  Using GtkComboBoxEntry...
  Adding 20000 entries took         734967 usec   ( 0.73 seconds).
  Realize widget took             32893081 usec   (32.89 seconds).

  Using GtkCombo...
  Adding 20000 entries took       18268379 usec   (18.27 seconds).
  Realize widget took                 1821 usec   ( 0.00 seconds).
Comment 3 Matthias Clasen 2004-09-25 04:05:27 UTC
If your comboboxes have more than 10000 entries, you have more serious problems
than performance... but it would certainly be good to speed up combo boxes where
possible. Was this tested with head, or with 2.4.x ? Head has a new list store
implementation which is backed by a splay tree, so should theoretically scale
better.
Comment 4 Billy Biggs 2004-09-25 15:36:50 UTC
Using the code from HEAD, there does not seem to be a large difference in the
results:

  Using GtkComboBoxEntry...
  Adding 20000 entries took         812270 usec   ( 0.81 seconds).
  Realize widget took             28655168 usec   (28.66 seconds).
Comment 5 Dru 2005-03-19 08:25:31 UTC
I write databases using GTK and i often deal with GtkTreeView's with 100k's of
records. They handle it ok but the GtkComboBox doesn't.  

I often get requests from users for a combobox listing all customers or all
products etc on their forms so they can quickly jump to record in a or quickly
search for what they need.  While I try to use GtkTreeView's in these situations
sometimes as well as multiple dropdown boxes to filter the results down, I
belive there is a situation where you would want a large listing where the
listings are properly sorted.

I couldnt download the attachment because of my browser, but in my apps for me
it takes a minute and a half to populate a GtkComboBox with 32k lists (longer
than the old code took). While it takes about 3 seconds to populate a lot more
complicated GtkTreeView with the same data in it.

If i unset the model before I populate the list the speed is greatly improved.
(a few seconds as i would expect). Though pango passes me UTF-8 errors and
rejects some of my record sets do not display at all, which is weird because
these same record sets work fine if i dont unset and reset the model.
Comment 6 Gustavo Noronha (kov) 2009-08-23 23:23:16 UTC
*** Bug 592051 has been marked as a duplicate of this bug. ***
Comment 7 logari81 2009-09-01 14:24:06 UTC
Created attachment 142248 [details]
testcase

This bug still exists in gtk+ 2.15, the attached testcase demonstrates it.
Comment 8 Jonathon Jongsma 2009-09-25 17:49:31 UTC
in case it's not obvious from the duplicate mentioned above, this bug is very visible in epiphany 2.28 (using webkit) since it seems to be much more common for websites to have large numbers of items in a combobox than it is for desktop apps.  It's quite painful to have to wait >5s after clicking a combobox to have it open.
Comment 9 Christian Dywan 2009-09-25 19:59:37 UTC
Note that "select" elements in WebKitGTK+ are not at all the same as GtkComboBox. It uses GtkMenu but the implementation is completely independent apart from that.
Comment 10 Benjamin Berg 2010-10-02 12:44:50 UTC
If I understand this bug correctly, the issue was, that building the menu takes so long. There is a simple workaround that can be done in applications, and that is to switch to the tree view mode (ie. use the GtkComboBox::appears-as-list style property).

I am attaching a patch that I wrote ages ago, but for some reason never attached to any bug. The main problem I identified back then was that appending menu items is much less efficient than prepending them.
Comment 11 Benjamin Berg 2010-10-02 12:46:23 UTC
Created attachment 171565 [details] [review]
the patch

This patch is *old*. I just remembered it was lying around and have not checked right now whether it actually still applies (but I will probably do that next).
Comment 12 Benjamin Berg 2010-10-02 15:06:58 UTC
OK, seems like the patch does not change anything (heck, it seemed like it got slightly worst, which I don't quite understand).

Some things to note though:
 1. Using gtk_combo_box_prepend_text makes adding entries a lot faster for me here
 2. At least with recent gtk+ versions, you need to popup the dropdown list to see how long it takes to create it. I added the following code:

    gtk_widget_show_all (window);

    while (gdk_events_pending ())
      gtk_main_iteration_do (FALSE);

    gettimeofday (&before, 0);
    gtk_combo_box_popup (GTK_COMBO_BOX (combobox));
    gettimeofday (&after, 0);

    fprintf (stderr, "Popup took\t\t%8d usec\t(%5.2f seconds).\n",
             timediff (&after, &before),
             ((double) timediff (&after, &before)) / (1000.0 * 1000.0));

 3. Popping up the choices is rather slow for menu mode, but really fast for treeview mode, which can be tried by putting the following into your ~/.gtkrc-2.0 for example:

style "test" {
        GtkComboBox::appears-as-list = 1
}
class "GtkWidget" style "test"


Maybe this helps someone else if they look into it.
Comment 13 Yaakov Selkowitz 2014-07-18 18:49:59 UTC
I still see this with bugzilla.redhat.com entries, and the aforementioned workaround doesn't seem to help.
Comment 14 Daniel Boles 2018-03-23 18:39:51 UTC
There's nothing here that isn't either years out of date or hopelessly vague. If this is still a practical issue as of GTK+ 3.22, someone needs to reopen with a compilable test case and examples of the timings you get.