Created attachment 31888 [details]
Test applications

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

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.

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

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.

*** Bug 592051 has been marked as a duplicate of this bug. ***

Created attachment 142248 [details]
testcase

This bug still exists in gtk+ 2.15, the attached testcase demonstrates it.

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.

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.

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.

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

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.

I still see this with bugzilla.redhat.com entries, and the aforementioned workaround doesn't seem to help.

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.