We currently create a fairly large number of module globals for the WebExtensions framework. This is nice for compartmentalization, but has the side-effect of creating a lot of additional memory overhead, particularly in terms of cross-compartment wrappers. One of the biggest culprits seems to be schema JSON data, which currently lives in the IndexedDB.jsm compartment in the parent process, or the privileged junk scope in the child, but is used mostly in Schemas.jsm. But there are plenty of other places where wrapper overhead adds up, too.

Kris, do you have any idea of the scale of memory impact this has? In bug 1186409 we're talking megabytes.

(In reply to Eric Rahm [:erahm] (please no mozreview requests) from comment #1) > Kris, do you have any idea of the scale of memory impact this has? In bug > 1186409 we're talking megabytes. Sorry, I don't remember the exact estimate that I came to before, but I think it was somewhere around 750K for the parent process, before OOP extensions, and some other changes that reduced a lot of our wrapper overhead. Right now, just looking at the about:memory section for the extension content process, we have about 190K of cross-compartment-wrapper-table overhead just for our our main framework compartments. I don't remember exactly how those memory reports work, but I'm pretty sure they don't include the size of wrapper objects, but only the lookup table, which would mean actual overhead is much higher. There's also the base per-compartment overhead, of course, and various other bits of non-wrapper compartment overhead.

Kris, is there still work to do here?

(In reply to Eric Rahm [:erahm] from comment #3) > Kris, is there still work to do here? Yes. Unfortunately, we still have a Sandbox to get rid of, which is currently blocked on bug 1393270. Which... I apparently fixed and forgot about.