Reference platform

All tests and charts were done on a Dell Mini 10v, with an 1.6 GHz dual core Atom CPU (i. e. rather slow), and a 16 GB SSD with a maximum read throughput of ~ 96 MB/s (according to palimpsest, confirmed by ureadahead bootcharts).

Boot charts apply to a stock Ubuntu install with autologin enabled, unless otherwise noted.

Boot times

Rounded to .5 s; note that the numbers do not add up perfectly, as the phases overlap, and there is always some inevitable noise.

Click headers for boot charts.

Desktop analysis

The main regression points are:

• aptdaemon is now being started during boot, turns out that it is due to indicator-session (see bug 850055); this adds a whopping 13 seconds. Boot chart with indicator-session disabled; Update: This bug has been fixed in oneiric now.

• nautilus CPU usage went from ~ 0.5 s to over 5 seconds. The wallpaper caching still works, so it's using lots of CPU for something now. To be investigated.
• unity used about 4 seconds in lucid (mutter plugin; mutter's CPU usage for non-unity was negligible). Now compiz/unity take about 8 seconds, plus another 3.5 for unity-panel-service, i. e. a times-three increase of CPU usage.

• Some parts of unity, like the lenses, are already only activated on demand, but are also quite heavy. If you press the windows key right after the desktop startup is visually complete, nothing happens for about 8 seconds. As you can see on the boot chart (this is still with indicator-session removed), the extra dash parts take about 6 seconds of CPU for loading, and then it suddenly pops up. This manifests in both the compiz process and the activated unity-applications-daemon process. I suspect this is doing some rather expensive reading of the apt package list, which should be deferred to when needed, or when the CPU gets idle, not done at startup of u-applications-daemon.

• zeitgeist-daemon is taking another two seconds, as it's a heavy python process. This is being fixed upstream by rewriting it in C.
• gnome-settings-daemon wastes quite a bit of time before registering with the session manager, and holds up the rest of the session until doing so. Notable things it does are:
  • Calls XRRGetScreenResources 3 times from 3 different plugins (each taking around ~0.5s on Intel hardware)
  • Takes a further ~0.5s iterating over each possible xrandr config file (due to XRR roundtrips), even if it doesn't exist. To check the backup, intended and default configs takes ~1.5s - even though none of these exist by default.
  • Calls pa_context_connect(), thus starting pulseaudio. This seems to block for ~1s, and seems unnecessary this early in the session.
  • Sets up the dbus proxy for the session manager asynchronously after claiming a common name (asynchronously) on the bus. This means that it may not even register with the session manager until after some other long-running idle callbacks have ran. This is one case where synchronous API is better than synchronous.