Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Per-tab memory accounting

91 views
Skip to first unread message

Nicholas Nethercote

unread,
Jun 16, 2011, 2:53:26 AM6/16/11
to dev-pl...@lists.mozilla.org
Hi,

I want to do per-tab memory accounting in about:memory. I have
reasonably good ideas how to do this, but any feedback would be
welcome. Below is something of a brain-dump.

----

A feature often requested by users is per-tab CPU and memory
accounting. Eg. https://bugzilla.mozilla.org/show_bug.cgi?id=400120.
It's also often suggested in forums. Per add-on accounting is also
often requested.

Once process separation is fully implemented, this won't be too hard,
because you can get that stuff from the OS. However, until then, it
would be good to have something.

Per-tab CPU accounting without process separation seems impossible.
(I'd love to be told otherwise, though.)

Per-tab memory accounting without process separation seems quite
possible. Here are the main memory reporter groups currently shown in
about:memory:

- js
- images
- storage
- layout
- heap-unclassified

It would be great to have the structure changed to something like this:

- Chrome
- js
- images
- layout
- storage
- Tab1
- js
- images
- layout
- Tab2
- js
- images
- layout
- heap-unclassified

I think doing memory reporting for images and layout (and the DOM,
when we get it --
https://bugzilla.mozilla.org/show_bug.cgi?id=663271) on a per-tab
basis shouldn't be too difficult.

I think storage memory (which is all SQLite) can't be easily split
among tabs, so putting it in the "Chrome" section seems the right
thing to do.

The heap-unclassified stuff obviously can't be broken down by a
per-tab basis. (https://bugzilla.mozilla.org/show_bug.cgi?id=563700
is open to add more reporters, thereby reducing the size of
heap-unclassified.)

For JS the situation is trickier. There the natural division is
per-compartment. https://bugzilla.mozilla.org/show_bug.cgi?id=661474
is open for adding per-compartment reporters to about:memory. (Note
that I've found this per-compartment info to be really useful already;
https://bugzilla.mozilla.org/show_bug.cgi?id=661068 and
https://bugzilla.mozilla.org/show_bug.cgi?id=664067 were created as a
result.)

Currently, one compartment can be shared between multiple tabs, which
makes a per-tab presentation difficult. But there are plans
(https://bugzilla.mozilla.org/show_bug.cgi?id=650353) for giving each
global its own compartment. Then compartments wouldn't be shared
between tabs, which would make per-tab accounting easier.

Another issue is that nsIMemoryReporter is not really a good interface
for per-tab reporters. The problem is that each memory reporter is
standalone and reports a single measurement, and about:memory iterates
over all of them. So if you open a new tab, you have to create
numerous new reporters: ones for images, ones for layout, etc. This
is doable -- it's what I've done for the per-compartment accounting --
but it's a bit painful and unnatural. What we really want is an
interface where about:memory says "give me all the JS numbers" and a
bit of code can go off and e.g. traverse the JS heap once, and return
N results, as opposed to N reporters which each traverse part of the
JS heap and each return 1 result. Shaver implemented something along
these lines in his prototype patch for about:compartments
(https://bugzilla.mozilla.org/show_bug.cgi?id=625305). So I can see
the current nsIMemoryReporter interface being phased out in favour of
something different.

Now, what about add-ons? AFAICT Jetpacks may open their own JS
compartment, so there is some scope for separate accounting there.
Other than that, I have no idea. It sure would be wonderful to be
able to avoid the "have you tried disabling add-ons?" ritual in leak
reports.

Another interesting problem is that this could become too successful.
Currently about:memory is a resource for developers and very technical
users. But if it has per-tab info, it becomes useful to less
technical users, for the use case "Firefox is crawling, which tab
should I close, or which add-on should I disable?" And then
about:memory's shortcomings -- lack of localization
(https://bugzilla.mozilla.org/show_bug.cgi?id=649881) and
over-reliance on ASCII art
(https://bugzilla.mozilla.org/show_bug.cgi?id=654917) will become
bigger issues. In which case a simpler task manager
(https://bugzilla.mozilla.org/show_bug.cgi?id=515352) would probably
be better. But that's a problem I'd be happy to have!

Nick

Mike Hommey

unread,
Jun 16, 2011, 3:15:14 AM6/16/11
to Nicholas Nethercote, dev-pl...@lists.mozilla.org
On Thu, Jun 16, 2011 at 04:53:26PM +1000, Nicholas Nethercote wrote:
> Hi,
>
> I want to do per-tab memory accounting in about:memory. I have
> reasonably good ideas how to do this, but any feedback would be
> welcome. Below is something of a brain-dump.
>
> ----
>
> A feature often requested by users is per-tab CPU and memory
> accounting. Eg. https://bugzilla.mozilla.org/show_bug.cgi?id=400120.
> It's also often suggested in forums. Per add-on accounting is also
> often requested.
>
> Once process separation is fully implemented, this won't be too hard,
> because you can get that stuff from the OS. However, until then, it
> would be good to have something.
>
> Per-tab CPU accounting without process separation seems impossible.
> (I'd love to be told otherwise, though.)

If there is a way to tell to what tab a specific event on the main event
loop is bound to, we might be able to do some accounting through the
main event loop.

... mmmm with all the caches we have around, aren't there a bunch of
things that are likely to be shared across tabs?

Mike

johnjbarton

unread,
Jun 16, 2011, 11:13:33 AM6/16/11
to
On 6/15/2011 11:53 PM, Nicholas Nethercote wrote:
> Hi,
>
> I want to do per-tab memory accounting in about:memory. I have
> reasonably good ideas how to do this, but any feedback would be
> welcome.

Per nsIDOMWindow would be *much* more useful. Modern apps have iframes
for components and addons often have their own windows. Being able to
zero in on the functional unit is key for finding problems. Organizing
the UI to put the nsIDOMWindows in a tree with tabs contentWindows
prominent would be great.

And/or: present the accounting so it matches the architecture. Tabs do
not in themselves hold memory. Apparently things called compartments do
hold memory. Presenting memory as it actually is used in the system
would go a long way towards helping developers improve their code.

Below is something of a brain-dump.
>
> ----
>
> A feature often requested by users is per-tab CPU and memory
> accounting. Eg. https://bugzilla.mozilla.org/show_bug.cgi?id=400120.
> It's also often suggested in forums. Per add-on accounting is also
> often requested.

At present most addons are not distinguishable from the browser:
overlays by design meld with the browser. Many addons do have
distinguishable parts. For example, Firebug has two iframe elements.
However the JS that runs those iframes is in browser.xul (up to 1.8). So
the memory for the JS is not in iframes.

jjb

Boris Zbarsky

unread,
Jun 16, 2011, 11:33:21 AM6/16/11
to
On 6/16/11 3:15 AM, Mike Hommey wrote:
> If there is a way to tell to what tab a specific event on the main event
> loop is bound to

There is not at the moment.

> .... mmmm with all the caches we have around, aren't there a bunch of


> things that are likely to be shared across tabs?

Images are shared across tabs.

Layout data is not (it's allocated in per-presshell arenas). JS njn
discussed already.

-Boris

Benjamin Smedberg

unread,
Jun 16, 2011, 11:41:59 AM6/16/11
to Nicholas Nethercote, dev-pl...@lists.mozilla.org
On 6/16/2011 2:53 AM, Nicholas Nethercote wrote:
> Once process separation is fully implemented, this won't be too hard,
> because you can get that stuff from the OS. However, until then, it
> would be good to have something.
We aren't likely to have strict per-tab processes. Instead, we'll have a
pool of content processes, and each tab will be assigned to one of the
content processes based on various heuristics. If one tab opens another
using window.open, they *have* to be in the same process, or at least
until a cross-process cycle collector is implemented, which is not
currently planned.

> Per-tab memory accounting without process separation seems quite
> possible. Here are the main memory reporter groups currently shown in
> about:memory:
>
> - js
> - images
> - storage
> - layout
> - heap-unclassified

There are some architecture issues which may make this difficult,
particularly in the image data. The image cache isn't directly
associated with tabs or DOM windows, especially when you have multiple
tabs open for the same site and they are sharing the image data.

> Now, what about add-ons? AFAICT Jetpacks may open their own JS
> compartment, so there is some scope for separate accounting there.
> Other than that, I have no idea. It sure would be wonderful to be
> able to avoid the "have you tried disabling add-ons?" ritual in leak
> reports.

We are actively working on moving at least jetpack-style addons into a
separate process. This was part of the original goal for the Jetpack SDK
1.0 but was not feasible this time. But even there, the addon will also
be able to run code in the context of content (content scripts), so
we'll have to do some combination of measurements. It probably isn't
feasible to do this work for old-style addons because they are basically
chrome and much of their code runs in the main browser window global.

--BDS

Nicholas Nethercote

unread,
Jun 16, 2011, 8:07:13 PM6/16/11
to johnjbarton, dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 1:13 AM, johnjbarton
<johnj...@johnjbarton.com> wrote:
>
> Per nsIDOMWindow would be *much* more useful. Modern apps have iframes for
> components and addons often have their own windows. Being able to zero in on
> the functional unit is key for finding problems. Organizing the UI to put
> the nsIDOMWindows in a tree with tabs contentWindows prominent would be
> great.
>
> And/or: present the accounting so it matches the architecture. Tabs do not
> in themselves hold memory. Apparently things called compartments do hold
> memory. Presenting memory as it actually is used in the system would go a
> long way towards helping developers improve their code.

This relates to the multiple use cases that I talked about. You're
focussing on the developer case. Users want per-tab stats so they
know which tab to close if memory use is excessive.

(Hmm, which developers do you mean -- Firefox developers, or web
developers? I'll assume the former.)

I was wondering/hoping to be able to satisfy both use cases in a
single view. Eg. if each JS compartment cannot be shared between
multiple tabs, it's reasonable to have a structure like this:

- TabA
- compartmentA1
- compartmentA2

which satisfies a user (per-tab info is there) and also a developer
(the compartments, which reflect the internal architecture, are
there).

But it sounds like there's more things shared across tabs (eg. images)
than I thought. So satisfying both kinds of user with about:memory
may be difficult.

Nick

Nicholas Nethercote

unread,
Jun 16, 2011, 8:09:00 PM6/16/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 1:33 AM, Boris Zbarsky <bzba...@mit.edu> wrote:
>
> Images are shared across tabs.

Can you clarify? If I have the same webpage open in multiple tabs,
will the images be shared between the tabs? In other words, any
single image doesn't necessarily belong to a single tab?

Nick

Joe Drew

unread,
Jun 16, 2011, 9:27:02 PM6/16/11
to dev-pl...@lists.mozilla.org
On 2011-06-16 8:09 PM, Nicholas Nethercote wrote:
> On Fri, Jun 17, 2011 at 1:33 AM, Boris Zbarsky<bzba...@mit.edu> wrote:
>>
>> Images are shared across tabs.
>
> Can you clarify? If I have the same webpage open in multiple tabs,
> will the images be shared between the tabs? In other words, any
> single image doesn't necessarily belong to a single tab?

Yes. We only ever have one copy of a given image in memory, even if it's
referenced on multiple pages.

(There are, I think, a couple of edge cases where this isn't the case,
but you can pretty much rely upon it.)

Joe

Robert O'Callahan

unread,
Jun 16, 2011, 10:12:17 PM6/16/11
to Nicholas Nethercote, dev-pl...@lists.mozilla.org
On Thu, Jun 16, 2011 at 6:53 PM, Nicholas Nethercote <n.neth...@gmail.com
> wrote:

> Once process separation is fully implemented, this won't be too hard,
> because you can get that stuff from the OS. However, until then, it
> would be good to have something.
>

As Benjamin said, process separation doesn't solve this problem, so whatever
you do will be relevant indefinitely. That's good news! :-)

Per-tab CPU accounting without process separation seems impossible.
> (I'd love to be told otherwise, though.)
>

I don't think it's impossible, in fact I think it might not be too hard, at
least for a partial solution. Here's a brainstorm for associating CPU usage
with documents (from which you can aggregate to get usage for tabs):
-- Give each thread a "current document" thread-local variable (which can be
null, since sometimes we don't know or it's browser-global). This would be
some sort of ID since document objects aren't thread-safe.
-- Create a "context switch" API that changes the current thread's current
document. This could help with the CPU accounting (or you could do sampling
if necessary)
-- Add document context switch calls at various places:
-- Layout phase-checking code (for reflows and restyles)
-- Triggering a DOM event handler
-- JS timers
-- Other async JS callbacks
-- Parser ops
-- Media decoding
-- Display list construction and ThebesLayer painting (some of the
painting is hard to account for because all the documents are mixed
together)
I reckon it wouldn't be hard to account for the majority of what most Web
apps do.

Bonus points if the context switch API takes a "type" parameter so we can
account for the *kind* of activity that's being triggered, and gets the
ability to log timestamps so we can get fine-grained performance timelines.

Rob
--
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]

Mike Shaver

unread,
Jun 16, 2011, 11:01:24 PM6/16/11
to rob...@ocallahan.org, dev-pl...@lists.mozilla.org, Nicholas Nethercote
On Thu, Jun 16, 2011 at 10:12 PM, Robert O'Callahan
<rob...@ocallahan.org> wrote:
> I don't think it's impossible, in fact I think it might not be too hard, at
> least for a partial solution. Here's a brainstorm for associating CPU usage
> with documents (from which you can aggregate to get usage for tabs):
> -- Give each thread a "current document" thread-local variable (which can be
> null, since sometimes we don't know or it's browser-global). This would be
> some sort of ID since document objects aren't thread-safe.
> -- Create a "context switch" API that changes the current thread's current
> document. This could help with the CPU accounting (or you could do sampling
> if necessary)

I had a prototype of this for JS compartments, including the types
(GC, parse/compile, script execute) based on the compartment-enter API
and rdtsc. I'll see if I can remember which computer I left it on.

Mike

johnjbarton

unread,
Jun 16, 2011, 11:30:24 PM6/16/11
to
On 6/16/2011 5:07 PM, Nicholas Nethercote wrote:
> On Fri, Jun 17, 2011 at 1:13 AM, johnjbarton
> <johnj...@johnjbarton.com> wrote:
>>
>> Per nsIDOMWindow would be *much* more useful. Modern apps have iframes for
>> components and addons often have their own windows. Being able to zero in on
>> the functional unit is key for finding problems. Organizing the UI to put
>> the nsIDOMWindows in a tree with tabs contentWindows prominent would be
>> great.
>>
>> And/or: present the accounting so it matches the architecture. Tabs do not
>> in themselves hold memory. Apparently things called compartments do hold
>> memory. Presenting memory as it actually is used in the system would go a
>> long way towards helping developers improve their code.
>
> This relates to the multiple use cases that I talked about. You're
> focussing on the developer case.

Because developers are the ones who can and will use the information.
Look at what happened with the Firebug Net panel, YSlow, Google page
speed, etc: now there is a whole industry built around load performance.

> Users want per-tab stats so they
> know which tab to close if memory use is excessive.

Really? I'd guess it's more like a tiny (relative to Firefox total)
number of (possibly vocal) technical users. We know what users want: the
Web content in that tab. We know that because they opened the tab. They
don't want to close the tab, they can't see the site then! Anyway, if
they run out of memory they'll probably reboot or go have a cup of tea,
because checking for tab memory is just not something they want to have
to do for their Web browser.

>
> (Hmm, which developers do you mean -- Firefox developers, or web
> developers? I'll assume the former.)

I don't think Firefox developers are in a position to do much about
memory. They are experts in their own areas and they are not sloppy. Web
developers on the other hand have no clue how much memory they are
using. On the other hand, Web developers have the expertise to find the
memory hog cases which can be fixed by the browser team. It's not going
to be "images take too many bits"; it's going to be "when we use ajax to
load images into iframes and the cache fails". You need information that
crosses expertise areas because the in-domain cases are well understood.
(plus I guess your tool is has real potential for web devs, but will be
too limited for specialty areas).

>
> I was wondering/hoping to be able to satisfy both use cases in a
> single view. Eg. if each JS compartment cannot be shared between
> multiple tabs, it's reasonable to have a structure like this:
>
> - TabA
> - compartmentA1
> - compartmentA2
>
> which satisfies a user (per-tab info is there) and also a developer
> (the compartments, which reflect the internal architecture, are
> there).

Yes, but this arrangement has the flaw that developers don't understand
how compartments are related to their code. We don't create
compartments, we don't see them.

>
> But it sounds like there's more things shared across tabs (eg. images)
> than I thought. So satisfying both kinds of user with about:memory
> may be difficult.

Since your goal is to blame particular web sites, just count the images
against all sites that use them. No one says the totals have to add up.

jjb

>
> Nick

johnjbarton

unread,
Jun 16, 2011, 11:35:15 PM6/16/11
to

Then add
-- GC
and record the process memory values at the switch points. Presto,
divide-and-conquer for memory.

Robert O'Callahan

unread,
Jun 17, 2011, 1:09:54 AM6/17/11
to johnjbarton, dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 3:30 PM, johnjbarton <johnj...@johnjbarton.com>wrote:

> On 6/16/2011 5:07 PM, Nicholas Nethercote wrote:
>
>> This relates to the multiple use cases that I talked about. You're
>> focussing on the developer case.
>>
>
> Because developers are the ones who can and will use the information. Look
> at what happened with the Firebug Net panel, YSlow, Google page speed, etc:
> now there is a whole industry built around load performance.


I think for Web developers we clearly want per-document (or per-DOM-window,
they're mostly equivalent here) data. Finer granularity is neither feasible
nor needed. So any infrastructure and APIs should be built around
per-document.

How we present the UI is another matter. I can definitely see per-tab usage
being useful to expose to users --- lots of non-developers use Task Manager
to see what's hogging their system, and killing off hoggy Web pages is
something that we should facilitate for normal users. But we can easily
compute per-tab information by aggregating per-document stats.

Nicholas Nethercote

unread,
Jun 17, 2011, 1:39:35 AM6/17/11
to rob...@ocallahan.org, dev-pl...@lists.mozilla.org, johnjbarton
On Fri, Jun 17, 2011 at 3:09 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
> But we can easily
> compute per-tab information by aggregating per-document stats.

Can we? My impression from this thread was that we can't, eg. because
images are shared between tabs, and other sharing.

Nick

Robert O'Callahan

unread,
Jun 17, 2011, 2:32:03 AM6/17/11
to Nicholas Nethercote, dev-pl...@lists.mozilla.org, johnjbarton

You're worried about double-counting resources that are shared across
multiple documents in the same tab?

That is a tough one, but I don't know how big a problem it would be in
practice.

Nicholas Nethercote

unread,
Jun 17, 2011, 3:05:44 AM6/17/11
to rob...@ocallahan.org, dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 4:32 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>
> You're worried about double-counting resources that are shared across
> multiple documents in the same tab?
>
> That is a tough one, but I don't know how big a problem it would be in
> practice.

The "explicit allocations" tree in about:memory (the version in FF6)
assumes no memory is double-counted and gives bogus results if it is.
Several cases of double-counting have been reported and fixed.

Now, we could present per-tab information through another channel, one
where overlaps could be tolerated. But that won't happen any time
soon.

Nick

Robert Kaiser

unread,
Jun 17, 2011, 11:21:22 AM6/17/11
to
johnjbarton schrieb:

> I don't think Firefox developers are in a position to do much about
> memory. They are experts in their own areas and they are not sloppy.

Dream on. We know that this is just not true, we have found memory usage
improvements in our own code time and again. And sometimes it's not
trivial to find out why or where you used more memory than wanted,
apparently.

And I know more educated users who want to know what Firefox is using
all that memory for than I know web developers, let alone those who are
concerned about their memory use. Those vocal, technical users are very
often those who tell web developers to actually look into the amount of
memory they're using.

Robert Kaiser


--
Note that any statements of mine - no matter how passionate - are never
meant to be offensive but very often as food for thought or possible
arguments that we as a community should think about. And most of the
time, I even appreciate irony and fun! :)

Mike Shaver

unread,
Jun 17, 2011, 11:22:42 AM6/17/11
to Nicholas Nethercote, dev-pl...@lists.mozilla.org, rob...@ocallahan.org, johnjbarton
On Jun 17, 2011 1:40 AM, "Nicholas Nethercote" <n.neth...@gmail.com>
wrote:
>
> On Fri, Jun 17, 2011 at 3:09 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:

> > But we can easily
> > compute per-tab information by aggregating per-document stats.
>
> Can we? My impression from this thread was that we can't, eg. because
> images are shared between tabs, and other sharing.

I don't think that's a huge problem. All modern operating systems have this
sharing, and people still manage to use process managers to reasonable
effect.

Put another way, I look forward to you creating for us the problem that our
memory accounting is too thorough, and that we therefore need to solve this
problem next!

Mike

Paul Biggar

unread,
Jun 17, 2011, 1:35:27 PM6/17/11
to Mike Shaver, dev-pl...@lists.mozilla.org, Nicholas Nethercote, rob...@ocallahan.org, johnjbarton
On Fri, Jun 17, 2011 at 08:22, Mike Shaver <mike....@gmail.com> wrote:
>> Can we?  My impression from this thread was that we can't, eg. because
>> images are shared between tabs, and other sharing.
>
> I don't think that's a huge problem. All modern operating systems have this
> sharing, and people still manage to use process managers to reasonable
> effect.

Sounds like the solution will be the same too: "Private" and "Shared".

--
Paul Biggar
Compiler Geek
pbi...@mozilla.com
@paulbiggar

Jean-Marc Desperrier

unread,
Jun 17, 2011, 1:46:34 PM6/17/11
to
johnjbarton wrote:
>> But it sounds like there's more things shared across tabs (eg. images)
>> than I thought. So satisfying both kinds of user with about:memory
>> may be difficult.
>
> Since your goal is to blame particular web sites, just count the images
> against all sites that use them. [...]

Firefox (at least the mobile version) could avoid keeping loaded (and/or
decoded) images that are not inside the view port of the page that uses
them. Would be interesting to see how much that would help.

Mike Shaver

unread,
Jun 17, 2011, 3:02:50 PM6/17/11
to Jean-Marc Desperrier, dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 1:46 PM, Jean-Marc Desperrier <jmd...@gmail.com> wrote:
> Firefox (at least the mobile version) could avoid keeping loaded (and/or
> decoded) images that are not inside the view port of the page that uses
> them. Would be interesting to see how much that would help.

Re-downloading on scroll would be a terrible user experience, IMO, but
just decoding again would be a good idea. We do it in Firefox 4. :-)

Mike

Kyle Huey

unread,
Jun 17, 2011, 4:37:05 PM6/17/11
to Mike Shaver, Jean-Marc Desperrier, dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 12:02 PM, Mike Shaver <mike....@gmail.com> wrote:

> On Fri, Jun 17, 2011 at 1:46 PM, Jean-Marc Desperrier <jmd...@gmail.com>
> wrote:

> > Firefox (at least the mobile version) could avoid keeping loaded (and/or
> > decoded) images that are not inside the view port of the page that uses
> > them. Would be interesting to see how much that would help.
>

> Re-downloading on scroll would be a terrible user experience, IMO, but
> just decoding again would be a good idea. We do it in Firefox 4. :-)
>

We do? I thought all of the images on the current tab were locked and not
subject to discarding.

- Kyle

Mike Shaver

unread,
Jun 17, 2011, 4:38:12 PM6/17/11
to Kyle Huey, Jean-Marc Desperrier, dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 4:37 PM, Kyle Huey <m...@kylehuey.com> wrote:
> On Fri, Jun 17, 2011 at 12:02 PM, Mike Shaver <mike....@gmail.com> wrote:
>>
>> On Fri, Jun 17, 2011 at 1:46 PM, Jean-Marc Desperrier <jmd...@gmail.com>
>> wrote:
>> > Firefox (at least the mobile version) could avoid keeping loaded (and/or
>> > decoded) images that are not inside the view port of the page that uses
>> > them. Would be interesting to see how much that would help.
>>
>> Re-downloading on scroll would be a terrible user experience, IMO, but
>> just decoding again would be a good idea.  We do it in Firefox 4. :-)
>
> We do?  I thought all of the images on the current tab were locked and not
> subject to discarding.

You are correct, thank you.

Mike

Boris Zbarsky

unread,
Jun 17, 2011, 4:48:52 PM6/17/11
to

It depends on which Firefox 4 you're talking about, no? Desktop and
mobile have somewhat different behavior here.

-Boris

Nicholas Nethercote

unread,
Jun 17, 2011, 5:37:33 PM6/17/11
to Mike Shaver, Jean-Marc Desperrier, dev-pl...@lists.mozilla.org
On Sat, Jun 18, 2011 at 5:02 AM, Mike Shaver <mike....@gmail.com> wrote:
>
> Re-downloading on scroll would be a terrible user experience, IMO, but
> just decoding again would be a good idea.  We do it in Firefox 4. :-)

https://bugzilla.mozilla.org/show_bug.cgi?id=660577 is related to that.

Nick

Jean-Marc Desperrier

unread,
Jun 18, 2011, 4:14:40 PM6/18/11
to
On 17/06/2011 21:02, Mike Shaver wrote:
> just decoding again would be a good idea. We do it in Firefox 4.:-)

Actually bug 573583, enable decode-on-draw, has not landed yet (has
been causing regression)
Comment 6 on it is very much what I was thinking.

Ted Mielczarek

unread,
Jun 20, 2011, 10:32:42 AM6/20/11
to rob...@ocallahan.org, dev-pl...@lists.mozilla.org
On Thu, Jun 16, 2011 at 10:12 PM, Robert O'Callahan
<rob...@ocallahan.org> wrote:
> -- Give each thread a "current document" thread-local variable (which can be
> null, since sometimes we don't know or it's browser-global). This would be
> some sort of ID since document objects aren't thread-safe.
> -- Create a "context switch" API that changes the current thread's current
> document. This could help with the CPU accounting (or you could do sampling
> if necessary)
> -- Add document context switch calls at various places:

This would have the neat side-effect that we could also use this data
for crash reporting to more accurately blame the correct URL...

-Ted

Joe Drew

unread,
Jun 20, 2011, 4:26:16 PM6/20/11
to dev-pl...@lists.mozilla.org

To be clear, landing bug 573583 should not have the "decode-on-draw"
functionality that most people expect it to have. As currently
formulated, "decode on draw" being turned on simply means that when you
open background tabs, the images on those tabs won't be decoded until
you bring that tab to the foreground, at which time all the images
visible on it will be decoded.

Jean-Marc Desperrier

unread,
Jun 21, 2011, 4:03:08 AM6/21/11
to
Joe Drew wrote:
>> Comment 6 on it is very much what I was thinking.
>
> To be clear, [...] As currently

> formulated, "decode on draw" being turned on simply means that when you
> open background tabs, the images on those tabs won't be decoded until
> you bring that tab to the foreground,

So, comment 6 seems to me to contain some good idea (even if experience
may show it doesn't actually work so well), will there be a specific bug
to test that sort of thing ?

> at which time all the images visible on it will be decoded.

You mean all the images referenced from it ? What does "visible" mean in
this context ?

Joe Drew

unread,
Jun 21, 2011, 12:04:16 PM6/21/11
to dev-pl...@lists.mozilla.org

On 2011-06-21 4:03 AM, Jean-Marc Desperrier wrote:

>> at which time all the images visible on it will be decoded.
>
> You mean all the images referenced from it ? What does "visible" mean in
> this context ?

At minimum all the images *drawn* (that is, the ones currently in the
viewport) will be decoded. I still need to check whether *all* the
images referenced on the webpage will be decoded at that time, so I made
a more restricted statement.

joe

Nicholas Nethercote

unread,
Jul 27, 2011, 8:44:52 PM7/27/11
to dev-pl...@lists.mozilla.org
On Fri, Jun 17, 2011 at 1:01 PM, Mike Shaver <mike....@gmail.com> wrote:
>> Here's a brainstorm for associating CPU usage
>> with documents
>
> I had a prototype of this for JS compartments, including the types
> (GC, parse/compile, script execute) based on the compartment-enter API
> and rdtsc. I'll see if I can remember which computer I left it on.

Given the success of per-compartment memory accounting (see
https://bugzilla.mozilla.org/show_bug.cgi?id=668871 for details ) I
think per-compartment CPU accounting is a great place to start.

billm had a copy of shaver's code and it's attached to the newly filed
https://bugzilla.mozilla.org/show_bug.cgi?id=674779, if anyone's
feeling inspired to take it on.

Nick

0 new messages