Visualizing the poor performance of the “Mozilla Platform”.
Today, thanks to this article, I saw a very telling diagram giving an overview of the “Mozilla Platform”. Before you read on, I encourage you to study the diagram for a few moments.
As anyone who has used a wide array of software knows, the various Mozilla offerings (eg. Firefox, Thunderbird, Seamonkey, etc.) tend to suffer from poor performance, and high memory usage. Thanks to the insanely-powerful desktop systems we have today, their software is usually tolerable. But even on such systems, most people will notice a significant improvement in responsiveness when using a browser like Opera, as compared to Firefox. Opera is usually quite a bit lighter than Firefox, as well, when it comes to memory usage.
Back to the diagram. I think it becomes obvious from looking at it why the Mozilla products suffer from such resource usage problems. One of the first things we should notice is the location of JavaScript within the diagram. It’s quite low, right above their cross-platform layer, the NSPR.
JavaScript, along with most other interpreted languages, is not known for its speed. Putting it so close to the foundation of your software system is just looking for performance trouble. With so many higher levels depending on it, it quickly becomes a performance bottleneck. Will Tamarin improve this area? Perhaps, somewhat. But in reality, its just-in-time compilation support may not offer all of the benefits that are anticipated.
Furthermore, we see quite a bit of layering. Software layering always becomes a tradeoff between at least runtime performance and developer productivity. Except in rare cases, such as OCaml, a higher level of abstraction tends to bring significant runtime performance decreases. Java is a perfect example of this. Mozilla, as a platform, may very well be another. Likewise, the abstraction tends to bring a significant cost in terms of increased memory usage.
What I would like to see is that diagram redone, but to show the relative size of each component. It may be difficult to pick an effective metric to use, so maybe several diagrams would be needed. In terms of source code, one could size the components based on lines of code, or perhaps even just the raw number of characters. A diagram scaled based on memory consumption would also be interesting, as would one scaled based on CPU usage.
Regardless, the current diagram does in fact do a good job showing why the so-called “Mozilla Platform” suffers from performance problems. Although work is under way to try to resolve some of these problems, these efforts may just not be enough. The very architecture of the “Mozilla Platform”, as shown in that diagram, has a bias against high runtime performance, and low memory usage.