{"id":43,"date":"2011-01-07T04:01:11","date_gmt":"2011-01-07T03:01:11","guid":{"rendered":"http:\/\/blog.mozilla.org\/jseward\/?p=43"},"modified":"2011-01-07T04:01:11","modified_gmt":"2011-01-07T03:01:11","slug":"space-profiling-the-browser","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/jseward\/2011\/01\/07\/space-profiling-the-browser\/","title":{"rendered":"Space profiling the browser"},"content":{"rendered":"<p>It&#8217;s been a good month or more since we started the current round of<br \/>\nchasing space problems in Firefox.\u00a0 Considerable effort has gone into<br \/>\nidentifying and fixing memory hogs.\u00a0 Although the individual fixes are<br \/>\noften excellent, I&#8217;ve haven&#8217;t had the big picture on how we&#8217;re doing.<br \/>\nSo today I did some 3 way profiling, comparing<\/p>\n<ul>\n<li>mozilla-central of today, incorporating essentially all the<br \/>\nspace fixes to date<\/li>\n<\/ul>\n<ul>\n<li>mozilla-central of 1 Nov last year, before this really got going<\/li>\n<\/ul>\n<ul>\n<li>1.9.2 of today, since that&#8217;s what we keep<br \/>\ngetting compared against<\/li>\n<\/ul>\n<p>These are release builds on x86_64 linux, using jemalloc, as that&#8217;s<br \/>\npresumably the least fragmentful allocator we have.<\/p>\n<p>Each run loads 20 cad-comic.com tabs.\u00a0 I let the browser run through<br \/>\n60 billion machine instructions, then stopped it.\u00a0 By<br \/>\naround 40 billion instructions it has loaded the tabs completely, and<br \/>\nthe last 20 billion are essentially idling, intended to give an<br \/>\nidentifiable steady-state plateau.\u00a0 That plateau ought to indicate the<br \/>\nminimum achievable residency, after the cycle collector, JS garbage<br \/>\ncollector, the method jit code thrower-awayer, the image discarder,<br \/>\nand any other such things, have done their thing.\u00a0 I regard the<br \/>\nplateau as more indicative of the behaviour of the browser during a<br \/>\nlong run, than I do the peak.<\/p>\n<p>I profiled using Valgrind&#8217;s Massif profiler, using the &#8211;pages-as-heap<br \/>\noption.\u00a0 This measures all mapped pages in the process, and so<br \/>\nincludes C++ heap, other mmap&#8217;d space, code, data and bss segments &#8212;<br \/>\neverything.<\/p>\n<p>Consequently a lot of the measured space is the constant overhead of<br \/>\nthe text, data and bss segments of the many shared objects involved.<br \/>\nThat cost is the same regardless of the browser&#8217;s workload.\u00a0 To<br \/>\nquantify it, I did a fourth profile run, loading a single blank page.<br \/>\nThis gives me a way to compute the incremental cost for each<br \/>\ncad-comic.com tab.<\/p>\n<p>The summary results of all this are (all numbers are MBs)<\/p>\n<ul>\n<li>Constant overhead: 526<\/li>\n<\/ul>\n<ul>\n<li>Total costs: 1.9.2 \u00a0 907,\u00a0 MC-Nov10\u00a0 1149,\u00a0 MC-now\u00a0 1077<\/li>\n<\/ul>\n<ul>\n<li>Hence incremental per-tab costs are:<br \/>\n1.9.2\u00a0 19.0,<br \/>\nMC-Nov10\u00a0 31.1 (63% above 1.9.2),<br \/>\nMC-now  27.5  (45% above 1.9.2)<\/li>\n<\/ul>\n<p>So we&#8217;re made considerable improvements since November.\u00a0 But we&#8217;re<br \/>\nstill worse than 1.9.2.\u00a0 Nick Nethercote tells me that bug 623428 should<br \/>\nbring further improvements when it lands.<\/p>\n<p>Here are the top-level visualisations for the three profiles.<\/p>\n<p>Firstly, 1.9.2 (picture below).\u00a0 What surprised me is the massive peak<br \/>\nof around 1.6GB during page load.\u00a0 Once that&#8217;s done, it falls back to a<br \/>\nseries of modest trough-peak variations.\u00a0 I took the steady-state<br \/>\nmeasurement above at the lowest trough, around 54 billion instructions<br \/>\non the horizontal axis.<\/p>\n<p>Also interesting is that steady-state is reached before 25 billion<br \/>\ninstructions.\u00a0 The M-C runs below took longer to get there.<\/p>\n<div id=\"attachment_45\" style=\"width: 748px\" class=\"wp-caption alignleft\"><a href=\"http:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/192.png\"><img aria-describedby=\"caption-attachment-45\" decoding=\"async\" loading=\"lazy\" class=\"size-large wp-image-45  \" title=\"Profile for 1.9.2\" src=\"http:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/192-1024x775.png\" alt=\"\" width=\"738\" height=\"558\" srcset=\"https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/192-1024x775.png 1024w, https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/192-300x227.png 300w, https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/192.png 1280w\" sizes=\"(max-width: 738px) 100vw, 738px\" \/><\/a><p id=\"caption-attachment-45\" class=\"wp-caption-text\">Profile for 1.9.2<\/p><\/div>\n<p>The M-C Nov10 picture (below) is less dramatic.\u00a0 It lacks the 1.6GB peak,<br \/>\ninstead climbing to pretty much the final level of around 1.2GB and<br \/>\nstaying there, with a slight decline into steady-state at around 44<br \/>\nbillion insns.<\/p>\n<p><a href=\"http:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-1nov10.png\"><img decoding=\"async\" loading=\"lazy\" class=\"alignleft size-large wp-image-46\" title=\"MC-1nov10\" src=\"http:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-1nov10-1024x815.png\" alt=\"Profile for M-C, 1 Nov 10\" width=\"738\" height=\"587\" srcset=\"https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-1nov10-1024x815.png 1024w, https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-1nov10-300x238.png 300w, https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-1nov10.png 1280w\" sizes=\"(max-width: 738px) 100vw, 738px\" \/><\/a><\/p>\n<p>The M-C-of-now picture (below) is similar, although steady state<br \/>\nis less steady, and somewhat lower, reflecting the fixes of the past<br \/>\nfew weeks.  Observe how the orange band steps down slightly in<br \/>\nthree stages after about 24 billion instructions.\u00a0 I believe that&#8217;s Brian<br \/>\nHackett&#8217;s code discard patch, bug 617656.\u00a0 Also, note the gradual<br \/>\nslope up from around 38 billion to 53 billion insns.\u00a0 That might be<br \/>\nthe excessively-infrequent GC problem investigated in bug 619822.<\/p>\n<p>So what&#8217;s with the 1.6GB peak for 1.9.2 ?\u00a0 It gives the interesting<br \/>\neffect that, although M-C is worse in steady state than 1.9.2, M-C<br \/>\nhas more modest peak requirements, at least for this test case.<\/p>\n<p>On investigation, what 1.9.2 seems to be spiked by is thread stacks.<br \/>\nThe implication is that it has more simultaneously live threads than<br \/>\nM-C.\u00a0 Why this should be, I don&#8217;t know.\u00a0 I did however notice that<br \/>\n1.9.2 seems to load all 20 tabs at the same time, whereas M-C appears<br \/>\nto pull them in in smaller groups.\u00a0 Related?\u00a0 I don&#8217;t know.<\/p>\n<p><a href=\"http:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-6jan111.png\"><img decoding=\"async\" loading=\"lazy\" class=\"alignleft size-large wp-image-48\" title=\"MC-6jan11\" src=\"http:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-6jan111-1024x815.png\" alt=\"Profile for M-C, 6 Jan 11\" width=\"738\" height=\"587\" srcset=\"https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-6jan111-1024x815.png 1024w, https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-6jan111-300x238.png 300w, https:\/\/blog.mozilla.org\/jseward\/files\/2011\/01\/MC-6jan111.png 1280w\" sizes=\"(max-width: 738px) 100vw, 738px\" \/><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>It&#8217;s been a good month or more since we started the current round of chasing space problems in Firefox.\u00a0 Considerable effort has gone into identifying and fixing memory hogs.\u00a0 Although the individual fixes are often excellent, I&#8217;ve haven&#8217;t had the &hellip; <a class=\"go\" href=\"https:\/\/blog.mozilla.org\/jseward\/2011\/01\/07\/space-profiling-the-browser\/\">Continue reading<\/a><\/p>\n","protected":false},"author":240,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts\/43"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/users\/240"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/comments?post=43"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/posts\/43\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/media?parent=43"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/categories?post=43"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/jseward\/wp-json\/wp\/v2\/tags?post=43"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}