{"id":1704,"date":"2012-02-08T12:22:40","date_gmt":"2012-02-08T01:22:40","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=1704"},"modified":"2012-02-08T13:44:19","modified_gmt":"2012-02-08T02:44:19","slug":"the-benefits-of-reducing-memory-consumption-2","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2012\/02\/08\/the-benefits-of-reducing-memory-consumption-2\/","title":{"rendered":"The benefits of reducing memory consumption"},"content":{"rendered":"

TL;DR: Any single change that reduces Firefox’s memory consumption can affect Firefox’s speed, stability and reputation in a variety of ways, some of which are non-obvious.\u00a0 Some examples illustrate this.
\n<\/strong><\/p>\n

The MemShrink wiki page<\/a> starts with the following text.<\/p>\n

MemShrink is a project that aims to reduce Firefox’s memory consumption. There are three potential benefits.\u00a0 Speed. […] Stability. […] Reputation.”<\/p><\/blockquote>\n

I want to dig more deeply into these benefits and the question of what it means to “reduce Firefox’s memory consumption”, because there are some subtleties involved.\u00a0 In what follows I will use the term “MemShrink optimization” to refer to any change that reduces Firefox’s memory consumption.<\/p>\n

Speed<\/h3>\n

People tend to associate low memory consumption with speed.\u00a0 However, time\/space trade-offs abound in programming, and an explicit goal of MemShrink is to not slow Firefox down — the wiki page says:<\/p>\n

Changes that reduce memory consumption but make Firefox slower are not desirable.<\/p><\/blockquote>\n

There are several ways that MemShrink optimizations can improve performance.<\/p>\n

Paging<\/h4>\n

The case that people probably think of first is paging.\u00a0 If physical memory fills up and the machine needs to start paging, i.e. evicting virtual memory pages to disk space, it can be catastrophic for performance.\u00a0 This is because disk accesses are many thousands of times slower than RAM accesses.<\/p>\n

However, some MemShrink optimizations are far more likely to affect paging than others.\u00a0 The key idea here is that of the working set size<\/a> — what’s important is not the total amount of physical or virtual memory being used, but the fraction of that memory that is touched frequently.\u00a0 For example, consider two programs that allocate and use a 1GB array.\u00a0 The first one touches pages within the array at random.\u00a0 The second one touches every page once and then touches the first page many times.\u00a0 The second program will obviously page much less than the first if the system’s physical memory fills up.<\/p>\n

The consequence of this is that a change that reduces the size of data structures that are accessed frequently is much more likely to reduce paging than a change that reduces the size of data structures that are accessed rarely.\u00a0 Note that this is counter-intuitive!\u00a0 It’s natural to want to optimize data structures that are wasteful of space, but “wasteful of space” often means “hardly touched” and so such optimizations don’t have much effect on paging.<\/p>\n

Measuring the working set size of a complex program like a web browser is actually rather difficult, which means that gauging the impact of a change on paging is also difficult.\u00a0 Julian Seward’s virtual memory profiler<\/a> offers one possible way.\u00a0 Another complication is that results vary greatly between machines.\u00a0 If you are running Firefox on a machine with 16GB of RAM, it’s likely that no change will affect paging, because Firefox is probably never paging in the first place.\u00a0 If you are on a netbook with 1GB of RAM, the story is obviously different.\u00a0 Also, the effects can vary between different operating systems.<\/p>\n

Cache pressure<\/h4>\n

Some MemShrink optimizations can also reduce cache pressure.\u00a0 For example, a change that makes a struct smaller would allow more of them to fit into a cache line.\u00a0 Like paging, these effects are very difficult to quantify, and changes that affect hot structures are more likely to reduce cache pressure significantly and improve performance.<\/p>\n

Structure traversals<\/h4>\n

Sometimes large data structures must be traversed, and reducing the number of elements in the data structure can reduce that traversal time.\u00a0 The obvious case for Firefox is the JavaScript heap — the garbage collector and cycle collector frequently traverse it, and so any change that causes dead objects to accumulate more slowly will reduce their traversal times.<\/p>\n

Only a small fraction of MemShrink optimizations will speed up structure traversals.<\/p>\n

Stability<\/h3>\n

If Firefox (or any program) uses too much memory, it can lead to aborts and crashes.\u00a0 These are sometimes called “OOMs” (out of memory). There are two main kinds of OOM:\u00a0 those involving virtual memory, and those involving physical memory.<\/p>\n

Virtual OOMs<\/h4>\n

A “virtual OOM” occurs when the virtual address space fills up and Firefox simply cannot refer to any more memory.\u00a0 This is mostly a problem on Windows, where Firefox is distributed as a 32-bit application, and so it can only address 2GB or 4GB of memory (the addressable amount depends on the OS configuration).\u00a0 This is true even if you have more than 4GB of RAM.\u00a0 In contrast, Mac OS X and Linux builds of Firefox are 64-bit and so virtual memory exhaustion is essentially impossible because the address space is massively larger.<\/p>\n

(I don’t want to get distracted by the question of why Firefox is a 32-bit application on Windows.\u00a0 I’ll just mention that (a) many Windows users are still running 32-bit versions of Windows that cannot run 64-bit applications, and (b) Mozilla does 64-bit Windows builds for testing purposes.\u00a0 Detailed discussions of the pros and cons of 64-bit builds can be read here<\/a> and here<\/a>.)<\/p>\n

The vast majority of MemShrink optimizations will reduce the amount of virtual memory consumed.\u00a0 (The only counter-examples I can think of involve deliberately evicting pages from physical memory.\u00a0 E.g. see the example of the GC decommitting change discussed below.)\u00a0 And<\/em> any such change will obviously reduce the number of virtual OOMs.\u00a0 Furthermore, the effect of any reduction is obvious and straightforward — a change that reduces the virtual memory consumption by 100MB on a particular machine and workload is twice as good as one that reduces it by 50MB.\u00a0 Of course, any improvement will only be noticed by those who experience virtual OOMs, which typically is people who have 100s of tabs open at once.\u00a0 (It may come as a surprise, but some people have that many tabs open regularly.)<\/p>\n

Physical OOMs<\/h4>\n

A “physical OOM” occurs when physical memory (and any additional backing storage such as swap space on disk) fills up.\u00a0 This is mostly a problem on low-end devices such as smartphones and netbooks, which typically have small amounts of RAM and may not have any swap space.<\/p>\n

The situation for physical memory is similar to that for virtual memory:\u00a0 almost any MemShrink optimization will reduce Firefox’s physical memory consumption.\u00a0 (One exception is that it’s possible for a memory allocation to consume virtual memory but not physical memory if it’s never accessed;\u00a0 more about this in the examples section below.)\u00a0 And any reduction in physical memory consumption will in turn reduce the number of physical OOMs.\u00a0 Finally, the effects are again obvious and straightforward — a 100MB reduction is twice as good as a 50MB reduction.<\/p>\n

Reputation<\/h3>\n

Finally, we have reputation.\u00a0 The obvious effect here is that if MemShrink optimizations cause Firefox to become faster and more stable over time, people’s opinion of Firefox will rise, either because their own experience improves, or they hear that other people’s experience improves.<\/p>\n

But I want to highlight a less obvious aspect of reputation.\u00a0 People often gauge Firefox’s memory consumption by looking at a utility such as the Task Manager (on Windows) or ‘top’ (on Mac\/Linux).\u00a0 Interpreting the numbers from these utilities is rather difficult — there are multiple metrics and all sorts of subtleties involved.\u00a0 (See this Stack Overflow post<\/a> for evidence of the complexities and how easy it is to get things wrong.)\u00a0 In fact, in my opinion, the subtleties are so great that people should almost never look at these numbers and instead focus on metrics that are influenced by memory consumption but which they can observe directly as users, i.e. speed and crash rate… but that’s a discussion for another time.<\/p>\n

Nonetheless, a non-trivial number of people judge Firefox on this metric.\u00a0 Imagine a change that caused Firefox’s numbers in these utilities to drop but had no other observable effect.\u00a0 (Such a change may be impossible in practice, but that doesn’t matter in this thought experiment.)\u00a0 One thing that has consistently surprised me is that some people view memory consumption as something approaching a moral issue:\u00a0 low memory consumption is virtuous and high memory consumption is sinful.\u00a0 As a result, this hypothetical change would improve Firefox’s reputation, rightly or wrongly, for the better.<\/p>\n

Let’s call this aspect of Firefox’s reputation the “reputation-by-measurement”.\u00a0 I suspect the most important metric for reputation-by-measurement is the “private bytes” reported by the Windows Task Manager, because that’s what people seem to most often look at.\u00a0 Private bytes measures the virtual memory of a process that is not shared with any other process.\u00a0 It’s my educated guess that in Firefox’s case that the amount of shared memory isn’t that high, and so the situation is similar to virtual OOMs above — just about any change that reduces the amount of virtual memory will reduce the private bytes by the same amount, and in terms of reputation-by-measurement, a 100MB reduction is twice as good as a 50MB reduction.<\/p>\n

Examples<\/h3>\n

Some examples help bring this discussion together.\u00a0 Consider bug 609905<\/a>, which removed a 512KB block of memory that was found to be allocated but never accessed.\u00a0 (This occurred because some code that used that block was removed but the allocation wasn’t removed at the same time.)\u00a0 What were the benefits of this change?<\/p>\n