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 567506 - Startup is slow when there are lots of users
Startup is slow when there are lots of users
Status: RESOLVED FIXED
Product: gnome-commander
Classification: Other
Component: application
unspecified
Other Solaris
: Normal normal
: 1.2.8
Assigned To: epiotr
epiotr
Depends on:
Blocks:
 
 
Reported: 2009-01-12 15:13 UTC by padraig.obriain
Modified: 2009-02-24 18:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Tweaks for faster startup (1.97 KB, patch)
2009-01-14 10:41 UTC, epiotr
none Details | Review
Measure the time of retrieving all users/groups (331 bytes, application/x-bzip)
2009-01-14 10:48 UTC, epiotr
  Details
New code for user/group handling (5.48 KB, patch)
2009-02-23 23:11 UTC, epiotr
none Details | Review
New code for user/group handling (5.48 KB, patch)
2009-02-23 23:11 UTC, epiotr
none Details | Review

Description padraig.obriain 2009-01-12 15:13:48 UTC
gnome-commander takes about 1 minute to start up.

The problem seems to be in lookup_all_users as there are over 44000 users.
Comment 1 epiotr 2009-01-12 22:43:26 UTC
Could you verify, please, if replacing g_list_append() with g_list_prepend() brings any speed-ups in:

static void lookup_all_users ()
{
    struct passwd *pw;

    setpwent ();

    while ((pw = getpwent ()) != NULL)
        all_users = g_list_append (all_users, create_user (pw, FALSE));

    endpwent ();

    all_users = g_list_sort (all_users, (GCompareFunc) compare_users);
}
Comment 2 padraig.obriain 2009-01-13 09:15:19 UTC
This improves things by about 15 seconds. However the calls to getpwent() still takes about 45 seconds.

What is the consequence of not getting all the users on startup?
Comment 3 epiotr 2009-01-13 19:43:23 UTC
Yet another iteration (rev. 2422): http://gcmd.rootnode.net/patches/gnome-commander-1.2.8-2422.tar.bz2

I've removed all unused data initialised/copied in lookup_all_users() and replaced g_list_append() with g_list_prepend() in lookup_all_groups(). That should save a few additional seconds.

Please do test.

BTW - users info is required for conversion of uid/guid into human readable form in the main file list. Unfortunately it can't be postponed
Comment 4 padraig.obriain 2009-01-14 08:37:22 UTC
I tried to build the tarball but it failed compiling gnome-tags-poppler.cc because include files like <poppler/PDFDoc.h> do not exist.

Could you send me a diff I could apply to 1.2.7?

I am concerned that your changes do not address the real problem which is that most of the time is spent in the calls to getpwent(). If all the users have to be retrieved I do not see how gnome-commander can start up in a timely way when there are a lot of users.
Comment 5 epiotr 2009-01-14 10:41:50 UTC
Created attachment 126412 [details] [review]
Tweaks for faster startup
Comment 6 epiotr 2009-01-14 10:48:01 UTC
Created attachment 126414 [details]
Measure the time of retrieving all users/groups

Could you run attached program to measure the time of retrieving all users/groups on your machine? TIA
Comment 7 padraig.obriain 2009-01-14 11:30:10 UTC
I have two systems on different networks and these are the results I get:

bash-3.2$ ./a.out
44494 users, 66.809600 s
231 groups, 0.315859 s

bash-3.2$ ./a.out
247 users, 0.047586 s
50 groups, 0.005758 s
Comment 8 epiotr 2009-02-23 23:11:01 UTC
Created attachment 129378 [details] [review]
New code for user/group handling

I've reimplemented the code responsible for user/group handling - here it goes:

 * information on user/group is retrieved on request
 * retrieved data is limited to minimum (currently uig/gid + name only)
 * retrieval of all user/group is done in separate thread (after gcmd startup)
 * mapping uid/gid -> displayed name is done using GHashTable (instead of previous GList).
   That should improve significantly directory read/redraw time for systems with lots of users

Please do test (apply attached diff to 1.2.7)
Comment 9 epiotr 2009-02-23 23:11:20 UTC
Created attachment 129379 [details] [review]
New code for user/group handling

I've reimplemented the code responsible for user/group handling - here it goes:

 * information on user/group is retrieved on request
 * retrieved data is limited to minimum (currently uid/gid + name only)
 * retrieval of all user/group is done in separate thread (after gcmd startup)
 * mapping uid/gid -> displayed name is done using GHashTable (instead of previous GList).
   That should improve significantly directory read/redraw time for systems with lots of users

Please do test (apply attached diff to 1.2.7)
Comment 10 padraig.obriain 2009-02-24 11:27:59 UTC
I have tried the attached patch and gnome-commander starts quickly with the patch applied.
Comment 11 epiotr 2009-02-24 18:10:53 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.