The time that Ubuntu takes to go from the GDM login prompt to a usable desktop is too long; it should be made faster.

Release Note

The time taken to login has been improved in Intrepid.


Users don't like to wait for a minute before being able to use their computer. Slow loading is visually jarring.

Use Cases


Several issues have been listed during the uds session and should be addressed


The previously indicated issue should be investigated before determining what changes are required exactly


KamilPáral: ionice with idle priority could be used to load some files during periods of heavy cpu usage activity

KrisMarsh: I notice that when I log in currently, an applet (I think it may be the clock + weather lookup applet) blocks the top gnome panel and effectively disables it for a few seconds. It would be nice if this wasn't allowed to happen (maybe if gnome-panel loaded applets in a different thread or something?)

MertDirik: "* xrdb is ran 3 times at login, figure why and reduce the number of calls if possible" This document has the answer

shaggy: My idea was to use the interactive login procedure time, when the system is idle, to readahead all files that will probably be needed. I reduced the login2desktop time from 54 seconds to 40 seconds that way. Using readahead-watch i created the list of files that are needed during my login-to-desktop phase. Then, i modified my gdm.conf with SoundProgram=/root/, where readahead-list reads all that files into the buffer/cache.

AlexJones2: Many GTK programs in the session start up before the settings manager is ready, so they get default settings including default theme engine, hicolor icon theme, etc., and then when the settings manager gets itself together, the programs then receive the user's preferred settings and then load ANOTHER theme engine ubuntu icon theme, etc. which is VERY expensive to do even once (just time how long even on an otherwise idle system it takes to change themes from, say, Clearlooks to Human in Appearance Switcher)

MikeRooney: Two comments. First, regarding your mention of starting nm-applet earlier, I thought some work was done in 0.7 to make starting up before login possible, so that could be something to look into. I don't know how it would handle encrypted wireless networks. Second, in the blueprint you mention "staged" startups, but I don't see a mention here. I think a refactor of the startup that loads compiz first before other things is crucial, especially for things that REQUIRE compositing support (AWN and Gnome-Do come to mind). Currently the only solution is to create a script which starts compiz, sleeps for a bunch of seconds, and then starts the things that need compositing, and then add that script to gnome-session startup and remove compiz and those apps. This is fairly awkward and confusing. We need to push compiz (when enabled as the default WM) deeper into the framework to eliminate issues like this, and what AlexJones2 said regarding applications currently loading twice.

TimoJyrinki: Mandriva has tackled many important issues in its 2009 release: link. Including killing network wait (1s), legacy pts generation (2s), udev coldplug (3s), usb-storage, dkms (2-4s), and fixing readahead not to cause regressions (2s), preload for desktop environment login (5s). I think all of these are a problem in intrepid, still - udev (&co) seems slow, dkms is really slow, readahead works very non-optimally and I think the network management also waits needlessly (Mandriva fixed it by checking whether network is needed for login or not), GNOME login time is awful.


BetterLoginSpeed (last edited 2009-09-23 15:25:42 by mail)