StartupSpeed
Differences between revisions 1 and 6 (spanning 5 versions)
|
Size: 2591
Comment:
|
Size: 5615
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| * '''Created''': | * '''Created''': 2009-11-25 |
| Line 6: | Line 6: |
| * '''Packages affected''': | * '''Packages affected''': compiz, gnome-menus, gnome-panel, gnome-session, gvfs, nautilus, pulseaudio, ubuntuone-client and probably quite some others |
| Line 10: | Line 10: |
| This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. See also CategorySpec for examples. | GNOME login needs to become much faster, the spec describes how we will achieve that. |
| Line 14: | Line 14: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) It is mandatory. == Rationale == This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. == User stories == == Assumptions == |
TODO |
| Line 28: | Line 18: |
| You can have subsections that better describe specific parts of the issue. | * 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, ... |
| Line 32: | Line 23: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: === UI Changes === Should cover changes required to the UI, or specific UI that is required to implement this === Code Changes === Code changes should include an overview of what needs to change, and in some cases even the specific details. === Migration === Include: * data migration, if any * redirects from old URLs to new ones, if any * how users will be pointed to the new way of doing things, if necessary. == Test/Demo Plan == It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. This need not be added or completed until the specification is nearing beta. == Unresolved issues == This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. |
See blueprint work items. |
| Line 61: | Line 27: |
| Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. | * 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 |
Launchpad Entry: 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
DesktopTeam/Specs/Lucid/StartupSpeed (last edited 2009-12-04 18:25:20 by ANancy-257-1-13-113)