about:memory has been thoroughly overhauled in FF6, and FF7 (now on
Aurora) extends it again to give measurements per JS "compartment",
which roughly means that JS measurements are broken down by the script
origins. Try it, it might help you a lot. See the first part of
http://blog.mozilla.com/nnethercote/2011/07/06/memshrink-progress-week-3/
for some more details.
Nick
On Jul 8, 4:43 am, Nicholas Nethercote <n.netherc...@gmail.com> wrote:
> On Fri, Jul 8, 2011 at 12:47 AM, passfree <passf...@googlemail.com> wrote:
> > Is this property from the about:memory page related to how much was
> > consumed by the main thread, and is it possible to get memory listing
> > per loaded XUL page? I am trying to pinpoint high memory usage.
>
> about:memory has been thoroughly overhauled in FF6, and FF7 (now on
> Aurora) extends it again to give measurements per JS "compartment",
> which roughly means that JS measurements are broken down by the script
> origins. Try it, it might help you a lot. See the first part ofhttp://blog.mozilla.com/nnethercote/2011/07/06/memshrink-progress-wee...
This is what I get from the about:memory
├──598,394,138 B (87.08%) -- js
│ ├──482,025,064 B (70.15%) -- compartment([System Principal])
│ │ ├──461,672,804 B (67.19%) -- string-chars
│ │ ├───12,529,664 B (01.82%) -- gc-heap
│ │ │ ├───6,085,104 B (00.89%) -- objects
│ │ │ ├───3,543,360 B (00.52%) -- shapes
│ │ │ ├───1,360,800 B (00.20%) -- strings
│ │ │ ├───1,284,184 B (00.19%) -- arena-unused
│ │ │ ├─────182,688 B (00.03%) -- arena-padding
│ │ │ ├──────73,416 B (00.01%) -- arena-headers
│ │ │ └─────────112 B (00.00%) -- xml
I presume compartment([System Principal]) is related to chrome. Does
that include workers instantiated from xul pages?
I don't know, sorry. But that's a huge string-chars number. You must
have a lot of long strings somewhere.
Nick
Can test by running one that creates a million objects and checking the
output, I bet. :-)
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
Ehsan
On 11-07-08 8:47 AM, Mike Shaver wrote:
> Yes, it should include the workers.
>
> Can test by running one that creates a million objects and checking the
> output, I bet. :-)
> On Jul 8, 2011 4:31 AM, "passfree"<pass...@googlemail.com> wrote:
> Would it be possible to create multiple compartments for chrome (such as,
> per XUL file/js module/etc)? I've noticed that with the per-compartment
> info on about:memory, chrome is the only part of the browser which seems
> like a black-box as far as the JS memory usage goes.
>
There has been talk of per-global-object compartments for some time now.
- Kyle
Andreas
On Jul 12, 2011, at 10:09 AM, Ehsan Akhgari wrote:
> Would it be possible to create multiple compartments for chrome (such as, per XUL file/js module/etc)? I've noticed that with the per-compartment info on about:memory, chrome is the only part of the browser which seems like a black-box as far as the JS memory usage goes.
>
> Ehsan
>
> On 11-07-08 8:47 AM, Mike Shaver wrote:
>> Yes, it should include the workers.
>>
>> Can test by running one that creates a million objects and checking the
>> output, I bet. :-)
>> On Jul 8, 2011 4:31 AM, "passfree"<pass...@googlemail.com> wrote:
Note that we have multiple compartments in chrome right this second,
that are all being reported together. In particular, each sandbox gets
its own compartment, but about:memory treats them as all identical.
I sort of wonder whether we could flag sandbox compartments with some
information about what created them (a callstack?) and expose all that
in about:memory... or something.
-Boris
> On 7/12/11 1:09 PM, Ehsan Akhgari wrote:
>> Would it be possible to create multiple compartments for chrome (such
>> as, per XUL file/js module/etc)? I've noticed that with the
>> per-compartment info on about:memory, chrome is the only part of the
>> browser which seems like a black-box as far as the JS memory usage goes.
>
> Note that we have multiple compartments in chrome right this second, that are all being reported together. In particular, each sandbox gets its own compartment, but about:memory treats them as all identical.
Right. For sandboxes we always had a wrapper in between, so this wasn't the kind of change in behavior we were worried about.
Andreas
>
> I sort of wonder whether we could flag sandbox compartments with some information about what created them (a callstack?) and expose all that in about:memory... or something.
>
> -Boris
I've opened bug 671159 to report them separately. Each one won't have
any distinguishing information, we can think about adding that later
if things are still unclear.
N
What are the other benefits? With my MemShrink hat on I'd love to
have a better breakdown of Chrome memory usage, but if that's the only
benefit and it makes life harder or slower in various other ways, it
might not be a good idea.
Nick
I don't expect this to be substantially slower. Extensions shouldn't be talking to frontend code all that much, and even if they do, we have to make wrappers fast anyway for one-global-per-compartment.
Andreas
>
> Nick
In that case, anything that can identify per-add-on memory usage would
be a godsend to both users and developers.
N
It would be nice to be able to minimise each branch of this, and extend
when needed. But I suppose something like that is probably done at the
moment.
I couldn't identify the "about:memory" compartment in my list ? Is it
the one shown as "about:void" ?
about:memory runs with the system principal, so it's already included in
the except.
--
Warning: May contain traces of nuts.
That's insane. 460MB of string data stored in chrome? What's going on
there?
-Boris
I filed bug 671352 for this.
Ehsan