Async and Responsive, issue 5

August 6, 2013 § 7 Comments

Summer, mosquitoes and vacations could not stop our heroes. Some of them braved the perils of working on the beach to improve the responsiveness of Firefox.

Session Restore

The plans for Session Restore have been overhauled to make way for code that is more e10s-friendly. Our plans to provide a main thread async API are therefore postponed indefinitely, in favor of a content script implementation of state collection. While less asynchronous than earlier prototypes, this implementation should also provide considerable responsiveness benefits, even before we turn on the e10s switch in Firefox. We have also overhauled part of the implementation of Session Restore to ensure that it caches state whenever appropriate, hence removing most of the jank due to state collection. Finally, we have started working on compressing communications between the main thread and the worker to minimize serialization costs. Additional clean-up has been completed, with more under way or is waiting for darker skies before landing.

Places

The titanic work to refactor Places into a non-blocking, off main thread, efficient API, continues. Ongoing works include making backups non-blocking and reducing the I/O cost of backups. We are also preparing a new asynchronous transaction manager for Places. Once this transaction manager has reached a satisfying state, it might be possible to reuse the code (or at least the design) for projects unrelated to Places.

Downloads

The JavaScript downloads API is basically ready. This API is fully asynchronous, JS-friendly and does just about everything off the main thread.

Misc

We are getting close to having a fully off main thread implementation of mozStorage. Partial rewrite/cleanup/modularization of OS.File continues, as well as extending and converting code to Promise.jsm. Also, additional work on porting synchronous code to OS.File.

Side-note

Our work with Async + Responsive has uncovered a number of bugs in the Firefox implementation of Workers and Chrome Workers. This, in itself, is not very surprising, as we are pushing these technologies into a number of places that hadn’t been explored yet. However, the owners of DOM:Workers have been extraordinarily reactive and we would like to thank them. Kudos, guys.

About these ads

§ 7 Responses to Async and Responsive, issue 5

  • Great post, please elaborate a bit on e10s and just how much work it requires accomplished prior to e10s being turned on by default in nightly channels.

  • Ken Magi says:

    This is great news. Recently I switch to Opera 15 because of how responsive it is when switching between tabs with 20 tabs open. In Firefox, it always lacks. Do you know when this will be landed in the nighty build or future release version? Thanks. Keep up the good work.

  • Would you please elaborate upon mozillas’ rust language, how it plays into e10s, firefox as a whole, and perhaps when we first shall see rust being implemented into firefox.

    Also regarding project async; what priority is main thread places for this project.

    Thanks.

    • yoric says:

      The Rust language is currently a research project at Mozilla. We are testing numerous things with Rust, but so far, as far as I know, we have no final plans on how we are going to integrate it to Firefox. I have seen people experimenting with the reimplementation of DOM and rendering in Rust, and initial results look encouraging, but that’s all they are so far: initial experimental results. In particular, I imagine that Firefox will be fully e10s before we start integrating Rust code into Firefox. I suspect that, in many years, we will have an architecture in which all safety-critical or platform-specific code will be written in Rust and all front-end code will be written in JavaScript and HTML5.

      Generally speaking, Rust is a new programming language designed to help developers build highly responsive, highly safe/secure applications for modern architectures. Rust places itself roughly in the same design space as C++ in terms of performance, access to low-level features and ability to link with C, Erlang in terms of concurrency, scalability, fault-tolerance, and OCaml/Haskell in terms of safety and security. From my (limited) experience, I believe that Rust is shaping up to be a great programming language, although I fear it might be as difficult to learn as C++.

      Regarding Async: off-main thread places is very much an active ongoing work.

  • Its would be just awesome if the UI was html; that said – what would happen to xul and would html enable more fine tune styling, combustibility, or would html simply impair those things? Any tracking bug for transitioning UI into html?

    Would you elaborate a bit if there is any correlation between mozillas’ rust and GPGPU. Since gpu programing is going to be incredibly easier very soon, as easy as C++, python ect, does mozilla have any plans of making use of such programing?

    Thanks for your very insightful explanations.

    • yoric says:

      I am not aware of precise plans to transition to HTML. However, XUL was designed because HTML was not powerful enough for User Interfaces. Now that HTML has gained/is gaining flexible layouts, responsive design, accessibility and (soon) a usable component mechanism, it would make sense to transition some or all of the UI to HTML5. I am not sure about localization, but the experience with Firefox OS seems to indicate that JavaScript libraries are sufficient and fast enough to do the trick. Also, Jetpack favors HTML and I seem to remember that some of Australis (our upcoming new UI) is coded in SVG rather than XUL, which puts us on the path towards that transition. I also cannot judge how much this will impact styling or composability (is this what you meant with “combustibility”?), but I certainly hope that this will open new opportunities for add-ons/theme authors.

      Regarding Rust vs. GPGPU, work has started on the topic. I don’t know where it will lead us, but it looks promising.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Async and Responsive, issue 5 at Il y a du thé renversé au bord de la table.

meta

Follow

Get every new post delivered to your Inbox.

Join 33 other followers

%d bloggers like this: