Announcing Project Async & Responsive

Project Snappy has been retired and replaced by several smaller projects, including Async & Responsive. The objective of this project is to improve the responsiveness of Firefox and the Mozilla Platform by converting key components to make them asynchronous and, wherever possible, to move them off the main thread.

The setting

Firefox and other Mozilla applications are great products, in particular in terms of performance. They are based on an extremely fast rendering engine, Gecko, and its companion JavaScript engine, which in addition to being the richest JS engine around, is also, these days, quite possibly the fastest. What is not so great, unfortunately, is that despite these great core performances, Mozilla applications have often been perceived as slow and sluggish.

Project Snappy was formed about 18 months ago to focus the effort by Mozilla developers to fight this perceived sluggishness. During this period, we have made tremendous progress, thanks to the commitment of everyone involved. Indeed, most of the long-term objectives of Snappy have been reached already. We have therefore decided to retire project Snappy, in favor of both a larger project Performance, and several sub-projects focusing on distinct aspects of Performance.

Let me introduce Asynchronous & Responsive [1], one of the sub-projects of Performance.

Project outline

Despite considerable progress, much of Firefox still behaves as a single-threaded application. Most services and components are initialized sequentially in the main thread, run in the main thread, are shutdown sequentially in the main thread. Also, most add-ons execute essentially in the main thread. As a consequence, any long-lived task can disrupt the user experience.

There are historical reasons for this, but in most cases, there is not deep blocker that would prevent us from rewriting services. Project Asynchronous & Responsive is now starting to support and focus the ongoing effort to get rid of main thread services and components, both in platform code and in add-on code, for the betterment of all Mozillakind.

I think both “Project Async & Responsive” and “Project Asynchronous & Responsive” don’t flow real well in English (and the latter is too long, if not the former as well).
The main thrust of the ‘how’ for the project is asynchronicity. I say just call it Project Async.
It’s quick to say and refer to, communicates what the project is mainly doing and people were going to find a way to shorten it anyway – this saves the trouble.

Async & Responsive and Electrolysis are two distinct projects, although we are working together on some topics.

Electrolysis is about having one or more “content processes” to execute everything that users see in tabs (mostly, but not only, webpages themselves) and one “chrome process” executing everything else (including the user interface, but also bookmarks, preferences, history, etc.). Electrolysis will ensure that heavy web content does not freeze the whole browser and that a crash in a tab does not take the entire browser with it. Some small bits of Electrolysis have landed recently on Nightly. I do not know of a specific calendar but my intuition tells me that we shouldn’t expect anything user-noticeable before 2014. Firefox OS itself uses Electrolysis everywhere.

Async & Responsive is about giving developers (both Firefox/Firefox OS developers and add-on developers) the necessary tools to let them write JS code that does not noticeably block the process in which they are executed. Async & Responsive has landed a number of refactorings (e.g. to Session Restore, to our database library, to file access, to downloads, to the way we handle bookmarks and history, etc.) and will continue to do so in parallel, mostly invisibly for users.

Yes thank you for your answer, I understand the differences now. About my second question (when will i be added to FF), in fact, the real question was: when will we be able to see a Firefox that “feels” as fast as Firefox? Even if benchmarks never demonstrate it explicitely, I find that FF “feels” slower than Chrome and I think that is it its biggest weakness.