Beyond the simple effort of avoiding loading jsms, there have been a number of ideas over the years for reducing the overhead from the giant swarm of system jsms that we have in every content compartment, at the level of the JS engine.
To get a sense of what overhead we could be eliminating by not having so many .jsms, I tried setting jsloader.reuseGlobal to true, then started the browser, loaded hacker news, minimized memory usage, then took a memory report. It looked like it reduced memory usage by around 3MB to 3.5MB in a content process. You end up with a new compartment that is about 510KB, but that eliminates about 2.5MB of direct compartment memory usage. The rest is various things like shapes (280kb saved), shared-immutable-strings-cache (250kb???), various XPConnect scope stuff (190kb), lazy scripts (150kb), object-groups/gc-heap (110kb), layout/rule-processor-cache (100kb???), shape tables (90kb), type-pool (40kb), unique id map (40kb), unused gc things (30kb).
I should add the disclaimer that there are a lot of error messages when I do that, so some memory savings could be from things failing to load.
11 months ago
Summary: Reduce content process memory overhead from system .jsms → [meta] Reduce content process memory overhead from system .jsms
5 months ago
No longer depends on: 1308512
You need to log in before you can comment on or make changes to this bug.