On 3/21/14, 1:37 AM, Nicholas Nethercote wrote:
On Fri, Mar 21, 2014 at 12:16 AM, Gregory Szorc <g...@mozilla.com> wrote:
Could someone please provide an update on reducing compartment overhead?
Are we at a point where things like services/healthreport/HealthReport.jsm should be considered a
"necessary evil" rather than a "gross hack?"
What other solutions besides concatenating files and lazy loading are there? Neither
sound particularly appealing to me. I'd really like to be able to "pin"
specific JSMs to shared compartments. Kind of a hybrid between CPG and the monolithic
compartment that came before. I filed a bug on that a year ago. Can't find it ATM...
I am unaware of any compelling stories to be told about reducing
compartment overhead at this time. Generational GC might help, though
I'm not sure. If compartment overhead was zero, we wouldn't have to
worry as much about this issue, but we live in an imperfect world and
have to work within constraints presented to us.
That's why I'm talking mostly about lazy loading -- it's a solution
that potentially gives us decent wins without too much trouble.
Firefox is a large program, and most users utilize only a fraction of
its features. Lazy loading parts that many users don't require
potentially helps memory consumption and start-up time.
I also don't see HealthReport.jsm as a problem. For one, it's not even
on the list. Furthermore, it seems like something that is needed right
from start-up, unlike many other compartments on that list.
If it's not in the list, then you aren't measuring properly.
Firefox Health Report - like a number of JS features - delays its main
module loading until a few seconds after profile-do-change. Components
do this to prevent churn during startup.
May I suggest changing your measurement technique to sample at least 60s
after browser startup?
Also, the bug I was referring to is bug 807205. It was marked WONTFIX
because gc now happens in zones rather than globals. But that bug was
concerned mainly with the overhead of cross-compartment string copying,
not compartment overhead.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
