On Mon, Mar 21, 2016 at 3:50 PM, Nicholas Nethercote <n.netherc...@gmail.com> wrote: > > - Heap overhead is significant. Reducing the page-cache size could save a > couple of MiBs. Improvements beyond that are hard. Turning on jemalloc4 > *might* help a bit, but I wouldn't bank on it, and there are other > complications with that.
I reduced the page-cache size from 4 MiB to 1 MiB in bug 1258257, saving up to 3 MiB per process. There was no discernible performance impact. > On Linux64, libxul contains about 5.3 MiB of static data. I've done some work to reduce this, as has Nathan Froyd, mostly under bug 1254777. I just did local Linux64 builds of the release branch and mozilla-inbound. The 'data' measurement provided by the |size| utility has dropped from 5,515,676 to 4,683,616 bytes, a reduction of 832,060 bytes. I also double-checked this by enabling memory.system_memory_reporter (which provides detailed OS-level memory measurements, Linux-only) and then looking at the appropriate "libxul.so/[rw-p]" entry in about:memory. The change there was from 5,472,256 to 4,685,824 bytes, a reduction of 786,432 bytes. I'm not sure why these numbers don't quite match the |size| numbers -- difference between on-disk an memory representations, perhaps? Nonetheless, they're similar. So that's the good news. The bad news is (a) there's still a long way to go before we can reasonably ship with more than 2 or perhaps 4 content processes enabled, (b) those changes above represent the lowest-hanging fruit I could find, and (c) I will have very limited time to work further on this in the medium-term. Nick _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
