Gmail is one of the most popular web-based email products. It is no secret that Gmail puts a noticeable strain on your browser and subsequently the entire computer. It may seem pointless to analyze why Gmail is bloated, considering it is an integral part of many users' business and even personal life.
Well, it turns out that studying the breakdown of Gmail's memory consumption has led us to some interesting discoveries.
We used Firefox to profile Gmail's memory usage. Like many web applications, Gmail incrementally downloads scripts and resources. We have interacted with the application until the memory consumption reached a stable level.
At the first glance, we see that Gmail takes up more than 100 megabytes of RAM. The majority of the RAM is divided into three equal parts: objects, domNode (DOM Nodes) and scripts.
In a plain, static HTML document, elements on the page are described by HTML tags. Each pair of tags denote what's known as a "node". Nested tags illustrate a hierarchy of nodes, much like a tree structure. All these nodes, or "objects" are part of the DOM, or "document object model".
Is script size the determining factor in web app's responsiveness? To answer this question, we looked at another heavy project - Jira, a web-based bug tracking software:
For comparison, we also included some products that are built with Antradar's coding practice (marked in blue).
Jira is not a single page application; it is a collection of a few functional modules. Within each module, or "view", there is a single page that acts like a mini Gmail. We have examined two common views in Jira - the Ticket view, and the Board view.
Jira's level of bloat is astounding, as if it's going for some Award of Inefficiency. The supposedly simple Ticket view dwarfs Gmail. The Board view is definitely reaching for the crown jewel.
Just to be fair, Jira is an engineering marvel in its own right. For those who are interested in Jira's front-end changes, here's an interesting video:
Given a development team that's approaching 400, Jira has no choice but to use many layers of abstraction. Unfortunately abstraction does not translate well to the front end. The memory chart shows that the Object size in Jira is not only large, but it surpasses its DOM Nodes.
Before we dive into the topic of DOM-to-Object ratio, let's also throw in some non-web app products for comparison:
An Architectural Advantage
We also see that Gyroscope applications have a rather high DOM-to-Object ratio. Furthermore, another Antradar product, FFC, exhibits an even higher ratio, as it is optimized for massive scale and performance:
Unused Memory is NOT Wasted Memory
There is a saying "unused memory is wasted memory" that's commonly used to defend bloated software. However, this saying is used out of context and is therefore utter nonsense.
Originally the saying was to point out, that if a piece of software uses disk instead of the much faster RAM, it is under utilizing the hardware resource. A reasonably designed operating system should use as much "real" RAM as possible before resorting to virtual memory that's backed by disk files.
On Android devices, obsessively freeing up RAM might be counter productive because of context switching penalty.
As far as web application goes, using less memory is definitely more efficient.
To put things in perspective, imagine that a family is going on a trip to Mars. Everything they need to bring on this one way trip must be bought. There is no point of leaving some money behind. "Unused money is wasted money". Within this Mars-bound family, there is a big eater, which we'll call Gee-Mal. Gee-Mal is inconsiderate and eats everyone's food. "uneaten food is wasted food", proclaims Gee-Mal. The rest of the family, along with the space crew, starve to death. End of story.