unity-api-bugs team mailing list archive

[Ted Gould <ted@xxxxxxxx>]

Introduction
============

To try and figure out what is happening on the application startup in
upstart-app-launch I added LTTng tracepoint support and measured the
startup in several cases.  Spanning both legacy and click apps along
with a secondary activation.  The times are slower than desired and can
be improved.

All tests were done on a Galaxy Nexus with Upstart App Launch trunk.

Browser Start
=============

The web browser is a legacy app, so we can look at that use-case.  But
it also has good support for secondary activation with multiple URLs, so
we can do that as well.  This test involved dispatching the
http://ubuntu.com URL and the http://canonical.com URL.

In the first instance case we see the time from Upstart signaling the
starting of the job until the first tracepoint of the legacy single
instance detection script taking about 550ms.  This time is primarily
click being used to detect with this is a click application.  After
deciding it isn't desktop-single is used to read the desktop file to see
if we're managing the single instance nature of the app (we are).
Determining that takes about 1.2ms.  Then we switch to using the
application-legacy job to manage the new instance.

It takes roughly 90ms to get from the application job to the first
tracepoint in the pre-start script of the application-legacy job.  This
is where we look for the Surface Flinger process.  It then connects to
DBus and immediately sends the starting handshake to Unity.  It takes
roughly 13ms to connect to DBus and send that signal.  To find the
desktop file parse it and setup the environment takes about 43ms.  We
then wait for Unity to return the handshake and go to exec.  Switching
from pre-start to the main exec utility seems to add an additional 43ms.

Overall from the start signal to exec'ing the process takes roughly
750ms.


Browser Secondary
=================

The secondary activation goes through the same first steps as the
browser, but after determining that we should be managing the single
instance nature of the app, it checks to see if it is running.  It seems
that this check takes 41ms.

It then takes us 10ms to setup DBus and emit the signal for Unity to
resume the app.  We then figure out the PID of the app we're looking
for, costing 13ms.  We then go massively parallel on DBus to figure out
which connection matches that PID.  The analysis of that is complex, but
at the end it takes us about 120ms to find the connection and send it
the new URL.  We then request focus from Unity and wait for about 14ms.

Overall it takes about 732ms to send the DBus message to the webbrowser.


Calculator Start
================

The calculator is a click application, so it goes through the
application-click path.  We don't have any tracepoint in the initial
application job.  For click packages it looks for the appid in click to
ensure it's a click app and then launches the application-click job.
Between the two start signals is 602ms.

When getting to the pre-start script for click packages the first thing
we do is initialize DBus and tell Unity the app is coming.  This takes
45ms.  The next thing we do is ask click for the package directory for
the package taking roughly 500ms.  We then configure the upstart
execution environment taking 100ms.  We then ask click for the package
manifest and parse the JSON taking 515ms.  We then parse the desktop
file, figure out the exec line and pass it to Upstart taking 25ms.

Unfortunately due to application confinement we can't see the execution
of the final process.  But considering this section is entirely the same
as the legacy path (on purpose) I think it's safe to assume it'll take
roughly the same 45ms.

Overall it takes about 1.8s to launch the calculator app.


Recommendations
===============

The single biggest issue seems to be calls to the click utility.  It
seems to take roughly 500ms per call.  Taking this into account we
should try and minimize calls.  The easiest to remove would be the one
in the application job and replaced with the symbolic links created by
the desktop hook.  This has no security implication as it's only used to
detect which type of package, not find more information about the
package.  Potential savings: 500ms.

Other uses would be more difficult to remove and should probably wait
for the development of libclick to be complete.  This would allow for
solving the paths and getting the manifest without spawning out external
processes.  Potential savings (for click packages only): Slightly less
than 1s.

The next biggest cost is setting up the Upstart environment.  This is
likely because we're doing each environment variable individually
instead of grouping and using a single DBus connection.  This can be
easily optimized.  Potential savings: 50-80ms.

Removing support for Surface Flinger seems prudent considering we're not
supporting it and it comes at relatively high cost.  Potential savings:
30ms.

These seem to be the largest optimizations available.  After completing
these items we should rerun the profiling to determine the next steps.

-- 
You received this bug notification because you are a member of Unity API
bugs, which is subscribed to Upstart Application Launcher.
https://bugs.launchpad.net/bugs/1257076

Title:
  Slow app startup time

Status in Upstart Application Launcher:
  Confirmed
Status in “unity-mir” package in Ubuntu:
  Confirmed
Status in “unity8” package in Ubuntu:
  Confirmed
Status in “upstart-app-launch” package in Ubuntu:
  Confirmed

Bug description:
  Since upgrading to trusty, applications have been taking longer and
  longer to load. While on the one hand, there is feature work and
  investigation to do, see:
  https://blueprints.launchpad.net/ubuntu/+spec/appdev-1311-sdk-apps-
  performance on the other hand, this is a regression and should be
  handled via a bug report for that reason.

To manage notifications about this bug go to:
https://bugs.launchpad.net/upstart-app-launch/+bug/1257076/+subscriptions