search

mozilla / r2d2b2g

Firefox OS Simulator is a test environment for Firefox OS. Use it to test your apps in a Firefox OS-like environment that looks and feels like a mobile phone.
https://addons.mozilla.org/en-US/firefox/addon/firefox-os-simulator/
Other
393 stars 139 forks source link

addon consumes significant processing time on startup #28

Open mykmelez opened 12 years ago

mykmelez commented 12 years ago

Jean Claveau noted in this blog comment that r2d2b2g takes 121ms on startup in this profile generated using Firefox's new SPS profiler.

That seems like a lot, and we should bring it down to a reasonable number (probably down to the low tens of ms, unless there is work that must be done on startup and has to take the time). Some of that time might be spent in SDK code that we don't control, but we should fix any issues in the r2d2b2g code and work around any issues in the SDK code that are possible to work around.

mykmelez commented 11 years ago

@kmaglione thinks this is because Firefox stats all the addon files, so we might be able to address this by moving the Simulator and Gaia profile out of the addon directory on install/update, although that would complicate the install/update experience, since it would mean that installing the addon isn't sufficient to install the Simulator, and users have to go through a second step (even if automated--they might still have to wait for it to happen and thus be informed of it) to complete installation.

For the Simulator itself, we can also make things better by omnijarring its files or using Firefox's XULRunner instead of shipping our own.

cc: @ochameau for any additional thoughts.

irvingreid commented 10 years ago

As part of the desktop performance team's work on reducing overall Firefox start up time, I've been looking into add-on performance. Aside from the problem of storing the profile in the install directory (issue #872), I recently added telemetry to Firefox to separately measure the recursive directory scan and the add-on's bootstrap startup() and shutdown() routines. The simulator add-on has the highest startup() time cost (median > 83ms, 75th percentile >230ms, 95th > 1260ms) and highest directory scan time cost (median > 160ms, 95% > 1700 ms) of all addons seen in more than 0.5% of Windows Nightly telemetry submissions. Aside from the notes above (using existing XULRunner, omnijarring), would it be possible to ship your entire add-on as a packed XPI, and then use your install() and unintall() bootstrap routines to unpack the necessary components into a separate directory, and clean them up afterwards?