Firefox 22 is now released, and I am very excited!  One of its key features is a new set of optimizations for asm.js, a highly optimizable subset of JavaScript.  asm.js was developed by Mozilla while working jointly with game industry leaders to find a path to port high performance C++ games to the Web.  That, however, is only the start of what it can do.

There are two main use cases that asm.js addresses.

The first is bringing full native applications to the Web.  Using a tool called Emscripten, C++ code can be cross-compiled to JavaScript, specifically the asm.js subset.  It integrates well with existing tool chains, as we have demonstrated by porting Unreal Engine 3 to the web in 4 days.  That’s an incredible achievement considering we ported over a million lines of code.  This accomplishment provides a smooth path towards publishing existing applications on the Web, or for treating the Web as a platform alongside traditional desktop and console targets.

Another route is using asm.js and Emscripten to port libraries that require significant computing power.  HTML5 game developers sometimes find it hard to achieve an acceptable user experience should they seek to include performance intensive elements such as physics or pathfinding in their game.  This often leads to developers needing to optimize every bit of their game just to get something workable.  asm.js makes including these intensive elements more practical.  You can now use an asm.js compiled library, such as Bullet or Box2d for physics, to supercharge the 5%-10% of the code that does most of the work and write the rest by hand using traditional JavaScript.  This approach gives you the speed of near-native execution where you need it and the ease and flexibility of modern JavaScript everywhere else.  Emscripten provides the needed capabilities for creating coder friendly interfaces for asm.js libraries to make them easy to interact with.


asm.js is not limited to games.  The performance it can bring to web applications opens up many interesting possibilities for speeding up existing web tasks, or bringing new experiences to the Web.  Efforts to port video decoders and photo processing tools using asm.js are also seeing performance increases from taking advantage of existing C++ code without plugins or browser-specific technology.

There have been several attempts to provide a solution for C++ developers wishing to target the Web.  We believe asm.js is the best solution, and here are a few of our reasons why:

1.  It’s just JavaScript.

asm.js is compatible with existing browsers.  Emscripten cross-compiled code requires Typed Arrays, a feature that is well-supported by modern browsers today, including Internet Explorer. There is no need to wait years for the technology to spread, or take the risk that it never will.  Furthermore, asm.js is a formalization of a pattern of JavaScript that web browsers have already been optimizing for, namely compiled C/C++ as generated by Emscripten and Mandreel, and a sample of that type of code appears in a popular benchmark, Google Octane.

2. It’s fast.

Thanks to all of the work browsers have already done to optimize JavaScript in general and compiled C++ in particular (in part due to such code appearing in Octane), it is very easy for browser vendors to optimize for it and unlock its full potential — it took a single Mozilla developer about 3 months to implement OdinMonkey, our asm.js optimization module for Firefox.  Google developers also quickly achieved large speedups on asm.js, as reported in their IO keynote. In just a short time it is possible to get to about half the native speed of C++.  That’s faster than Java, in the case of Box2D.  That is just the first draft – we expect to get much closer to native performance with additional development on the browser side.

3. It dramatically reduces the cost of supporting the Web.

For developers already working with C++, Emscripten makes the Web just another port target.  Once it’s integrated into your tool chain, the web version can be recompiled alongside your other platforms whenever any updates are needed.  We have ported full properties in very short time periods.

4. It reduces or eliminates the need for plugins.

Companies that turn to plugins to enable their games or applications often see a significant friction in user adoption due to security warnings.  asm.js provides an alternative path that eliminates the security messaging issue while still providing much of the performance, all within a safe execution environment.

5. It enables reuse of existing C++ libraries.

There is a wealth of open source C++ libraries out there waiting to come over to the Web.  This is a vast amount of coding effort whose value has now been unlocked for web developers.

asm.js is still a new technology, and we have plenty of work to do to provide its full potential to the developer community.  Mozilla is grateful to Epic and other game industry leaders that have already started to work on products using asm.js.  These early examples are helping to prove the value, shape the technology, and encourage other browsers to priorities optimizations for it.  The best way to help support the development of asm.js is to start using it and let us know what you think by adding comments to this post.  If you are a game developer or have a performance intensive application and choose to port it over, share your work with the world and let us know about it!

For an in-depth look into what asm.js is and isn’t, have a look at this post by Alon Zakai. Well worth the read!

It has been almost 6 months since the project started so I thought it was way overdue to recap how things have been going.  I am excited about the interest this project is receiving from both active Mozilla Contributors (employees and volunteers) and the academic community.  I’m working hard to deliver on your hopes for direct access to the results of this project.

Update on the Interviews

The Bugzilla Anthropology project has been moving along well when it comes to the interview work.  We have completed 20 interviews plus 2 write-ins during the first quarter of this year.  The raw transcripts are posted at the following link:

Work has been ongoing to parse through and summarize the results of these interviews into a digestible form.  We have had considerable help from Olga Baysal and Reid Holmes from the Cheriton School of Computer Science at the University of Waterloo who are working tirelessly to parse through all the data we collected.  They are categorizing the 1,213 comments gathered over the course of the interviews.  This will result in two documents, the first is a 3 page summary that available at the following link:

This initial document discusses how the final longer summary will be categorized and how much activity was seen in each one.

Thank you very much Olga and Reid, this is a huge effort and we really appreciate your work so far.  I eagerly await seeing the final 25-30 page summary.

Update on the Metrics

We have been working with the Mozilla Metrics team to surface information that can help us better visualize macro trends as they play out in Bugzilla.  This will help us measure change over time and see problems coming before they reach a critical point.  To help deal with the massive scope of the information stored in Mozilla’s Bugzilla, we are copying some of this data into an Elastic Search database that only includes the meta data of each bug.  This lets us do massive queries without hindering production by bringing Bugzilla’s DB to a standstill.  Progress on this work has been slower than I would like but we are making gradual progress.

We are working to make this data public via a REST interface but in the mean time, for those that have LDAP level access at Mozilla, you can see some of the visualization prototypes we have been working on at the following link:

Several of these prototypes are in use in production already.  However, work is still ongoing and here is what stands between us and a public REST interface:

1. Complete schema modification to make sure that the database can handle queries relating to review queues.

2. Insure that proper automated testing is in place to verify that the data in the ES database is consistent with that found in Bugzilla’s DB.  We have seen issues here so this is important.

3. Address the remaining security concerns around the meta data associated with open security bugs.

None of these are that large in scope, however, the metrics team has been very tied up and has had difficulty finding time to work on them.  Last week saw a jump in progress on the first item and I’m hopeful we will see that crossed off the todo list soon.  I have also attended very constructive meetings that show this rising in priority for the Metrics team which is also a positive sign we will see this done sooner than later.

Project Wiki Page:


What is this all about?

The goal of the program is to take a deep look at how people are currently engaging with Bugzilla. We want to see what we can learn about the tool’s good, bad, and frustrating qualities. You can’t look at Bugzilla without understanding how people work. The research is also surfacing information on the life cycle of bugs and how people interact with them along the way. The primary goals are as follows:


  • Identify the information we want to gather.
  • Interview stakeholders across the organization and community.
  • Surface statistics that are relevant to its use.
  • Identify best practices, useful hacks, tools, and key problem areas.
  • Provide an overview of how Bugzilla is being used.
  • Complete the research by the end of January 2012.


How are we going about doing this?

In an effort to get to the root causes of issues and find the hidden best practices, we are gathering data in two ways. First, we are conducting 1 hour interviews that probe into various topics focusing on how people interact with bugs throughout their life cycle.

The second method is statistical. We are diving into the considerable dataset we have stored in Bugzilla’s historical log. We hope to surface trends that help point out problem areas where we can improve as well as shed light on what’s working well so we can highlight those successes.


What have we learned so far?

We have just completed 10 interviews and posted the raw transcripts last week. We held off posting this material until we felt we had the absolute minimum representative coverage. The transcripts are raw feedback, they have been verified by the contributors, and they have all volunteered, in true Mozillian fashion, to put their names on them. Thank you to all the brave contributors that went first in the hopes of improving things for all.


Interview Transcripts:


We have also been working with Metrics to gather data on Bugzilla usage. Much of this data is still behind layers of security as the tools that help visualize trends are still prototypes. Once the tools are ready, the security group will need to review the system as it includes statistical information on security bugs. We will need to work with them to double check that we aren’t leaking out sensitive material before reducing the security to LDAP or preferably making it publicly available.


How can people contribute?

The best way to help is to review the data, give us feedback on a new set of interview candidates, and anything new you think we should be exploring. We intend to do another 10 interviews as the next phase. We will be including more community members in this round as they are currently under represented. The current list of questions we are asking and who is on our radar as candidates can be found at the following Etherpad. Feel free to add suggestions here:


Interview Etherpad:


Once we start to surface the statistical side, I will write up another post.

If you have any questions you would like to see added to the interviews, have any feedback on the project or results that you would like to share, you can find me on IRC in the #pm channel, email me at or comment below.