Launchpad Entry: better-login-speed
Packages affected: xorg, gdm, gnome-settings-daemon, compiz, gnome-session, gnome-control-center, jockey, evolution, tracker, network-manager, xdg-user-dirs-gtk, system-config-printer, gnome-screensaver
Summary
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.
Rationale
Users don't like to wait for a minute before being able to use their computer. Slow loading is visually jarring.
Use Cases
- Daniel starts his work day, he turn on his computer and go to get a cup of coffee, when he comes back he expect to be able to read his email without waiting another 15 seconds
Design
Several issues have been listed during the uds session and should be addressed
- xorg is taking a lot of time to start
- the gdmprefetch binaries seems to do nothing, it should either be fix or replaced
- xrdb ("X resource database manager") is ran 3 times at login, figure why and reduce the number of calls if possible
- commands are running in a sequential way because they use the environment previously set
- compiz is taking a lot of time and using the disk a lot
- gnome-panel is light but applets are using the disk a lot
- several processes using the disk at the same time is slower, the new gnome-session address that
- gnome-at-visual is using gconftool
- jockey-gtk is not delayed as expected
- evolution-alarm should be started later
- trackerd is still using lot of disk when it's told to do nothing
- nm-applet should be started first
- xdg-user-dir-gtk should run only if the language has changed and maybe go to gnome-settings-daemon
- system-config-printer should be started after the desktop is loaded
- gnome-screensaver not needed there
Implementation
The previously indicated issue should be investigated before determining what changes are required exactly
Comments
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 http://www.colitti.com/lorenzo/publications/gnome-sane.pdf
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/readahead.sh, 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.