
Simply put: the more content processes we use, the more memory we use.
We list the memory usage for each checkpoint using 0, 1, 2, 4, 8 content processes. ForceGC: We manually invoked garbage collection. Settled: 30 seconds have passed since previous checkpoint. For a more realistic baseline I chose to use a combination of RSS and USS (aka unique set size, private working bytes): total_memory = RSS(parent_process) + sum(USS(content_processes)) Note: Just summing the total memory usage of each Firefox process is not a useful metric as it will include memory shared between the main process and the content processes. Wait 10 seconds per tab.įor this test I performed two iterations of this, reporting the startup memory usage from the first and the end of test memory usage (TabsOpen, TabsClosed) for the second. Open 100 urls in 30 tabs, cycling through tabs once 30 are opened. Open Firefox configured to use N content processes. This test runs through a sample pageset, the same one used in Talos perf testing, in an attempt to simulate a long-lived session.
Methodologyįor the test I used a slightly modified version of the AWSY framework that I maintain for. Starting Q4-2015 I began setting up a test to measure the memory usage of Firefox with a variable amount of content processes. The concern here is simple: the more processes we have, the more memory we use.
FIREFOX MEMORY MONITOR FULL
With the e10s project full steam ahead, likely to be enabled for many users in mid-2016, it seemed like a good time to measure the memory overhead of switching Firefox from a single-process architecture to a multi-process architecture.