Le jeudi 24 avril 2014 10:51:12 UTC+2, Nicholas Nethercote a écrit :
> I've given the list of current start-up
> (+30s) modules below.
This list contains several compartments for XPCOM components handling the
command line (eg. nsSetDefaultBrowser.js or nsDefaultCLH.js). I wouldn't expect
them
On 4/24/14, 1:51 AM, Nicholas Nethercote wrote:
There are
still 16 compartments whose name includes "devtools", for example.
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1001131 for lazily
loading devtools modules where it makes sense.
___
dev
On Thu, Mar 20, 2014 at 11:46 PM, Nicholas Nethercote
wrote:
>
> At start-up, with a new profile, Firefox creates more than 230 system
> compartments.
I just measured again and got 198, which is great! The start-up
numbers on AWSY have improved by maybe 5-10 MiB since I started this
thread. (Unfo
среда, 26 марта 2014 г., 5:10:45 UTC+2 пользователь Nicholas Nethercote написал:
> On a related note, I just noticed that in my current session a lot of
> the system compartments appear twice or even more. Does anyone know
> how this can happen? I only have one browser window open.
If you have Sty
On Fri, Mar 21, 2014 at 5:00 PM, Nicholas Nethercote
wrote:
> On Fri, Mar 21, 2014 at 6:31 AM, Benjamin Smedberg
> wrote:
>>
>> What is the per-compartment overhead?
>
> It's hard to pin an exact number on it.
I talked to Bill about this today, and the overhead includes:
- The JSCompartment obj
On Friday, March 21, 2014 12:16:28 AM UTC-7, Gregory Szorc wrote:
> 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
On Fri, Mar 21, 2014 at 5:44 PM, Nicholas Nethercote
wrote:
>
> I should clarify: that's the memory consumption that's identified as
> belonging to the compartment, but that's not the whole picture. Some
> compartment data gets reported at the level of the runtime, including
> 'script-sources' and
On Fri, Mar 21, 2014 at 2:00 PM, Nicholas Nethercote
wrote:
>>
>> What is the per-compartment overhead?
>
> It's hard to pin an exact number on it. It depends on exactly the
> mixture of GC things allocated by the compartment. But in my current
> session, the smallest two system compartments take
- Original Message -
> From: "Nicholas Nethercote"
> To: "Benjamin Smedberg"
> Cc: "dev-platform"
> Sent: Friday, March 21, 2014 2:00:01 PM
> Subject: Re: Too many system compartments at start-up
>
> Marco identified a number of modul
On Fri, Mar 21, 2014 at 6:31 AM, Benjamin Smedberg
wrote:
>
> What is the per-compartment overhead?
It's hard to pin an exact number on it. It depends on exactly the
mixture of GC things allocated by the compartment. But in my current
session, the smallest two system compartments take up only 4,7
On Fri, Mar 21, 2014 at 2:45 PM, Andrew McCreight wrote:
> Looking at a recent AWSY run, in StartSettled, I see three non-window
> zones.
>
> One is about 22mb and contains all the stuff you'd expect, browser.xul,
> various .jsm files etc.
>
> The second is is 2.8mb, almost entirely strings. Ther
Looking at a recent AWSY run, in StartSettled, I see three non-window zones.
One is about 22mb and contains all the stuff you'd expect, browser.xul, various
.jsm files etc.
The second is is 2.8mb, almost entirely strings. There's one string that is
about 10,000 long, but the rest are non-notab
On Fri, Mar 21, 2014 at 2:23 PM, Boris Zbarsky wrote:
> On 3/21/14 1:09 PM, Bobby Holley wrote:
>
>> For JSMs and stuff, they should all go into the system zone.
>>
>
> I realize that, emphasis on "should". Have we verified that this is
> happening?
Maybe bill did, at some point? This is prett
On 03/21/2014 12:06 PM, Bill McCloskey wrote:
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 wo
On 3/21/14 1:09 PM, Bobby Holley wrote:
For JSMs and stuff, they should all go into the system zone.
I realize that, emphasis on "should". Have we verified that this is
happening?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On Fri, Mar 21, 2014 at 1:37 PM, Boris Zbarsky wrote:
> On 3/21/14 11:02 AM, Bobby Holley wrote:
>
>> I'm also curious to hear about the overhead of compartments now that we
>> have zones.
>>
>
> An important question: which of these system compartments actually share a
> zone with each other? I
On 3/21/14, 9:06 AM, Bill McCloskey wrote:
- Original Message -
From: "Bobby Holley"
To: "Benjamin Smedberg"
Cc: "dev-platform" , "Nicholas Nethercote"
Sent: Friday, March 21, 2014 8:02:58 AM
Subject: Re: Too many system compartments at star
On 3/21/14, 9:36 AM, Bill McCloskey wrote:
- Original Message -
From: "Gregory Szorc"
To: "Nicholas Nethercote"
Cc: "dev-platform"
Sent: Friday, March 21, 2014 9:27:34 AM
Subject: Re: Too many system compartments at start-up
Also, the bug I was refe
On 3/21/14 11:02 AM, Bobby Holley wrote:
I'm also curious to hear about the overhead of compartments now that we
have zones.
An important question: which of these system compartments actually share
a zone with each other? I know the goal is "all of them", but are we
actually getting there?
- Original Message -
> From: "Gregory Szorc"
> To: "Nicholas Nethercote"
> Cc: "dev-platform"
> Sent: Friday, March 21, 2014 9:27:34 AM
> Subject: Re: Too many system compartments at start-up
>
> Also, the bug I was referring to is
On 3/21/14, 1:37 AM, Nicholas Nethercote wrote:
On Fri, Mar 21, 2014 at 12:16 AM, Gregory Szorc 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" ra
- Original Message -
> From: "Bobby Holley"
> To: "Benjamin Smedberg"
> Cc: "dev-platform" , "Nicholas Nethercote"
>
> Sent: Friday, March 21, 2014 8:02:58 AM
> Subject: Re: Too many system compartments at start-up
>
>
On Fri, Mar 21, 2014 at 10:31 AM, Benjamin Smedberg
wrote:
> On 3/21/2014 2:46 AM, Nicholas Nethercote wrote:
>
>> Hi,
>>
>> At start-up, with a new profile, Firefox creates more than 230 system
>> compartments. This is about 90 more than a year ago, and it's part of
>> the reason why Firefox uses
On 21/03/2014 15:37, Benjamin Smedberg wrote:
On 3/21/2014 10:34 AM, Marco Bonardo wrote:
Or directly make Cu.import act like defineLazyModuleGetter... Would
that be possible?
I don't think that's a good idea. It's not an uncommon pattern to
try/catch around a module import in case it's not p
On 3/21/2014 10:34 AM, Marco Bonardo wrote:
Or directly make Cu.import act like defineLazyModuleGetter... Would
that be possible?
I don't think that's a good idea. It's not an uncommon pattern to
try/catch around a module import in case it's not present in a
particular configuration or the
I started filing some low-hanging-fruit dependencies, though, looks like
one of the main culprit is modules that are Cu.import-ed instead of
defineLazyModuleGetter-ed.
I wonder if we could somehow instrument Cu.import so that if a module is
not used before N seconds (or M ticks?) from when it
Nicholas Nethercote schrieb:
Hi,
At start-up, with a new profile, Firefox creates more than 230 system
compartments. This is about 90 more than a year ago, and it's part of
the reason why Firefox uses almost twice as much physical memory at
start-up than it did two years ago.
Hrm, reading your
On 3/21/2014 2:46 AM, Nicholas Nethercote wrote:
Hi,
At start-up, with a new profile, Firefox creates more than 230 system
compartments. This is about 90 more than a year ago, and it's part of
the reason why Firefox uses almost twice as much physical memory at
start-up than it did two years ago.
If my memory serves, B2G has its own implementation of Cu.import that
doesn't create components. Would it be possible to expose this
implementation to Firefox so that we could use it for some modules that
are designed to be always be imported together?
I would definitely use this for OS.File.
Sim
On Fri, Mar 21, 2014 at 12:16 AM, Gregory Szorc 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 sol
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?
Ne
31 matches
Mail list logo
