On 3/21/14, 9:06 AM, Bill McCloskey wrote:
----- Original Message -----
From: "Bobby Holley" <bobbyhol...@gmail.com>
To: "Benjamin Smedberg" <benja...@smedbergs.us>
Cc: "dev-platform" <dev-platform@lists.mozilla.org>, "Nicholas Nethercote"
<n.netherc...@gmail.com>
Sent: Friday, March 21, 2014 8:02:58 AM
Subject: Re: Too many system compartments at start-up
I'm also curious to hear about the overhead of compartments now that we
have zones. I was under the impression that most of it was CCW overhead,
which shouldn't really be an issue in the startup case, since we should
have very few wrappers.
As far as I know, we haven't done any measurements of compartment overhead
since zones landed (bug 759585). The whole point of zones was that people
shouldn't have to merge compartments just to save memory, so I hope people
don't start doing that without any data. All of the measurements in bug 986323
simply say that we're loading a lot more code now than we were before. No
amount of merging compartments will fix that.
The problem with doing measurements is that the per-compartment overhead is
very dependent on what's going on in the compartment. I tried to enable the B2G
compartment merging stuff in desktop Firefox to get a sense of how much of a
change there would be [1]. It's hard to tell if it actually saved anything. It
broke a lot of stuff, and I had a hard time getting consistent measurements of
memory use at startup since the numbers really fluctuate wildly. My best guess
is that explicit went from 90MB currently to 70MB with merging. That's a lot,
but keep in mind that a bunch of exceptions are thrown all over the place, and
we might just be failing to load some important stuff. Hopefully someone can
follow up on this.
Great reply Bill!
I'm interpreting your response as "the number of compartments isn't a
problem: the total volume is." In other words, our incentive is to load
as little code/JavaScript as possible at all times. (That should go
without saying.) Or, ignore many of the responses earlier in this thread :)
Let's talk about ways to make that happen. I'll start with a few ideas:
1) Require all new JS features to have a pref that can disable loading
of extra modules/code. That way, we can disable prefs of features and
measure the overhead of each feature. I would love a dashboard of
per-feature overhead, especially one with a time axis so I can identify
regressions over time.
2) Change how JavaScript "services" work so the js/jsm that is loaded as
part of XPCOM startup is as minimal as possible and performs as few
immediate imports as possible. This minimizes the import cost during
XPCOM initialization.
3) Don't initialize a JS-based XPCOM service until it is actually
accessed or needed. For optional browser services (like bookmarks), no
JSMs get imported until someone makes an API call that accesses the
service. Perhaps JS-based service objects/interfaces should be exposed
as promises?
4) Explore a proper service management framework for initializing
components, dependencies and all. This has been talked about before and
is arguably long overdue.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
