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 111830 - gdmsetup has scaling performance issues
gdmsetup has scaling performance issues
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.4.1.x
Other All
: Normal normal
: ---
Assigned To: GDM maintainers
Trevor Curtis
Depends on:
Blocks:
 
 
Reported: 2003-04-29 10:40 UTC by Brian Cameron
Modified: 2005-03-15 02:39 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
image of the proposed "General" tab. (48.21 KB, image/png)
2003-04-29 10:41 UTC, Brian Cameron
Details
Image of the proposed pop-up (37.38 KB, image/png)
2003-04-29 10:41 UTC, Brian Cameron
Details

Description Brian Cameron 2003-04-29 10:40:23 UTC
When I run gdmsetup, it takes several minutes (1-4 minutes) to start.
It spends most of its time in the following function:

 fe596538 getpwent_r (16056c, 160590, 400, 245110, 245728, 1000) + 4c
 0001c77c setup_user_combo (319fc, 31a0c, 1389c8, e64, fe782d70, feee2a50)
+ 19c 0002109c setup_gui (64, 3225c, 44a44, 0, ffbfee54, c) + 11c
 00021bf4 main     (1, ffbfee54, ffbfee5c, 45800, 0, 0) + 2f4
 0001b128 _start   (0, 0, 0, 0, 0, 0) + 108

This happens because I am on a large network which has several thousand
users, so it is spending all this time getting userid values.  These
userid values are used to populate the "Automatic login username" and
"Timed login username" combo boxes in the "General" tab.

If I try to click on either of these two combo boxes, the program has
to pause for an additional minute simply to display this ridiculously
long list of several thousand userids.

Calum Benson, the human factors engineer here at Sun, put together
the following proposal regarding how the UI should be set up.

---

I think we probably going to want the list to appear in a separate
dialog.  I'd probably change the dropdown lists to text fields with
a "Choose..." button beside them... see first screenshot.

The popup dialog probably needs to be modal, so you can't pop up two
versions of it at the same time by clicking both "Choose..." buttons in
the parent dialog... that would just be confusing.

What actually happens in the dialog depends a lot on how asynchronous
you can make the username-collecting process.

Ideal situation: while the search is progressing, the list populates
with the usernames that are found in real time.  In the screenshot, I've
also added a column for the full name... dunno if this information is
available or desirable at this point, but it seemed useful to me :)  The
list remains interactive during the search... that is, if I saw my
username appear in the list, I could select it and click OK without
having to wait for the search to complete.  Some secondary feedback
would probably also be required (when the list gets very long, you won't
see the list filling up or the scrollbar moving any more)... you could
maybe animate the icon in the top left corner, and/or use some text
under the list to indicate progress.  (I'm assuming there's no way to
use a determinate progress indicator here that could show percentage
complete or ETA).

Worst case situation: until the search is complete, the list just
contains the word "Searching..." and the OK button is disabled. While
the cursor is over the window, it changes to an 'arrow-plus-hourglass'
shape.  The only interaction the user can have with the window is to
press the "Cancel" button to cancel the search and close the dialog,
though.

Either way, the list of usernames would ideally be cached locally until
both dialogs were dismissed... you wouldn't want the search to happen
again when you pressed the Choose Timed Login button if you'd just done
it for the Choose Automatic Login button...
Comment 1 Brian Cameron 2003-04-29 10:41:24 UTC
Created attachment 16097 [details]
image of the proposed "General" tab.
Comment 2 Brian Cameron 2003-04-29 10:41:57 UTC
Created attachment 16098 [details]
Image of the proposed pop-up
Comment 3 George Lebl 2003-05-13 16:57:41 UTC
I'm checking in a partial fix where the code will refuse to add
more then 50 users.  That should work much better at least for now.
I'm leaving in a FIXME in the code as well.
Comment 4 shane o'connor 2003-08-12 11:50:23 UTC
I just tested this on sun's gnome2.2_06 which is running gnome-panel
version 


Only 52 users are displayed but there is still a very, very long wait
of upto 7 minutes while doing the lookup before displaying the login
screen - 
Comment 5 shane o'connor 2003-08-12 12:11:29 UTC
mmmmm, looks like this might be a network issue for us 
Comment 6 George Lebl 2003-08-14 17:00:02 UTC
in CVS head what I did was limit the time this is to take by time.  If
it takes more then 5 seconds then we stop reading new users with
getpwent.  However if it takes 7 minutes to getpwent 52 users, that's
8 seconds per one getpwent, you're having some serious issues.  It
could perhaps be however that it is not each getpwent call that is
this long, but perhaps the setpwent and endpwent for some reason. 
This can obviously impact the network if you're using NIS.
Comment 7 Brian Cameron 2005-03-15 02:39:36 UTC
Now the browser uses the Include keyword so the sysadmin can define which
specific users appear in the face browser or in the Automatic/Timed login list.
 There is
a IncludeAll option that is turned on by default.  The user can set IncludeAll
to true if they want the current behavior of scanning the password file.