Comment 6 for bug 1257076

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.