##(see the SpecSpec for an explanation) * '''Launchpad Entry''': UbuntuSpec:desktop-lucid-startup-speed * '''Created''': 2009-11-25 * '''Contributors''': * '''Packages affected''': compiz, gnome-menus, gnome-panel, gnome-session, gvfs, nautilus, pulseaudio, ubuntuone-client and probably quite some others == Summary == GNOME login needs to become much faster, the spec describes how we will achieve that. == Release Note == TODO == Design == * Review the current login chart, determine what is slow and make it faster for lucid * Backup plan if speed is not good enough: don't use compiz by default, turn nautilus desktop rendering off by default, ... == Implementation == See blueprint work items. == BoF agenda and discussion == * compiz * large number of plugins, reading all different files * some 75 plugins in total * drop shell script wrapper, done in compiz.real now * split package, don't install optional ones * investigate "everything linked in" * gnome-panel * reading all desktop file and gettext()ing it (one .mo file for each application) * create per-language cache file for all applications in a dpkg trigger, and change gnome-menus to read it if present * test without app menu, and test without any applets * nautilus * thumbnails all files during startup each time, even if it's not meant to (should use the cache) * when moving the plugins away, startup time reduced to a third * totem-properties: lazily initialize gstreamer, do nothing at startup * investigate other plugins accordingly * delayed by gnome-panel, to determine final nautilus screen area; could change to start both at the same time, and send a signal when nautilus shoudl render its icons (done by setting a property on the root window) * ubuntuone-client * applet will go away * defer startup of the sync daemon, and move the token check into the autostart .desktop file instead of checking within the Python daemon * gnome-settings-daemon * forks a process which does a lot of writes * pulseaudio wrapper: should be able to go away (for autolaunch) * gvfsd-trash * thumbnails the trash -> to be investigated == Reviews == === gnome-session === * gnome-session exhibits a slightly greater than 1 second delay before starting gnome-settings-daemon on the reference hardware * The greatest contributors to this delay are detailed below: || '''Task''' || '''Time''' || '''Comment''' || || Preloading GConf keys || 500ms || GConf keys currently used for required components list, default components, idle timeout setting and monitoring autostart conditions for session clients (such as vino-server) || || Setting up DkpClient || 150ms || Calling dkp_client_new() when DK-Power is not running (which is the case with auto-login) takes a long time as DK-Power is activated || || gtk_init_with_args() || 80ms || Does option parsing and initializes GTK || || GConf check || 60ms || gnome-session spawns gconf-sanity-check-2, and then waits for it to finish after setting up the XSMP server || || Loading desktop files || 50ms || || ==== Ideas / suggestions ==== * Delays due to reading GConf keys * Investigation work has demonstrated that the first GConf call in a session always seems to take a long time (whether it is to read a single key or preload a directory. * Should aim to delay reading any GConf keys in gnome-session before starting the core session components (g-s-d, WM, panel, nautilus) * Read default session / required components from a keyfile rather than GConf. * Delay reading of idle timeout value until session has loaded. * Some applications have autostart conditions based on GConf values (eg, vino-server). gnome-session currently sets up the monitors when loading the desktop files. This should be delayed until the phase where the application is ready to run * These steps work, but only really shift the delay later in to the session (testing shows that g-s-d takes a longer time to load with these changes in gnome-session, which delays the INITIALIZATION -> WINDOW_MANAGER phase transition. There are other steps to try which might improve this though * Setting up DkpClient * Calling dkp_client_new() when gnome-session is initialized from auto-login can take a long time, as it activates the DK-Power daemon. * This should be deferred until it is actually needed by gnome-session (ie, when calling the session dialog). * Deferring it will mean that g-p-m will activate the daemon when it loads later in the session, but we should have a usable session by then (and that won't block other components loading). * gtk_init_with_args() * There's not really any easy way to avoid this. * Perhaps it may be possible to move GTK related stuff in to a separate helper (out of the main daemon). That would be a lot of work though. * GConf check * The delay due to waiting for gconf-sanity-check-2 to exit can be minimized by starting it earlier in the session ==== Other observations ==== * On a machine with a rotary disk, it can take ~200ms to read the autostart desktop files. * In a VirtualBox guest, it took ~100ms to query ConsoleKit over D-Bus for the session type. The session type is used to determine whether to restore a saved session (if one exists). * The delay wasn't observed on the reference hardware (might be because the VBox guest is single-core) * Can be avoided anyway by checking if there is a saved session to restore from === gnome-panel === * empty gnome-panel takes around 1 second full cpu use to start * seems there is quite some non busy time during loading, why? * the stock applets (notification area, tasks list, workspace switcher) don't add too much use * menu applet: * the bootchart with only this applet shows light cpu use for several seconds, is that due to idle callback loading? * clock applet * delay the e-d-s init to be done later (either after loading or in a mouseover callback for example)? * need to investigate why the temperature and weather icon options add activity when there is no location configured === gnome-settings-daemon === * the 1 second delay between g-s-d and next components is mostly due to xrandr, to investigate * don't call xrdb: https://bugzilla.gnome.org/show_bug.cgi?id=586276 ---- CategorySpec