Firefox fat on Javascript?

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Firefox fat on Javascript?

Michael Witten-2
[I apologize to the members of the [hidden email] mailing list,
 who have basically received 2 copies of this email; I didn't realize
 I needed to be subscribed to the other mailing lists before posting,
 and I wanted to keep you in the loop--but I guess that's kind of
 silly anyway, because maybe you can't talk to each other anyhow...]

Firefox has always eaten way too many resources in my opinion, and my
hunch is that the Javascript engine is largely to blame, but I must
admit that I'm quite possibly wrong about that and have not done any
appreciably technical testing on the matter.

Currently, I'm running 3 instances of Firefox (because Firefox handles
profiles in a broken way). I usually use the `Vimperator' extension,
but I've only enabled it on one of these instances:

  Profile                     Usage                       top's %Mem (RES)
  -------                     -----                       ----------------
     0       Reading news (aggregators and otherwise),
             watching YouTube and other Flash video,
             making `First!' posts on slashdot, reading
             technical documentation, searching for
             everything via Google, editing Wikipedia,     14.2% (143 MiB)
             etc. I pretty much do a little bit of
             everything with this instance and spend
             most of my time on the web using it.

     1       Basically just sitting there with one
             browser window opened to my Gmail account;
             I haven't been using it much lately... it     24.6% (248 MiB)
             has literally just sat there, unused with
             Gmail ticking in the background.

     2       Running Vimperator with a few of [what I
             think are] relatively static pages just
             sitting there; maybe I'll make an             26.4% (266 MiB)
             occasional Google search, but it mainly
             goes unused.

Guys, what is going on here?

I realize that there are all sorts of wonky things that come into play
with regard to memory usage (glibc gobbling up memory and never telling
Linux it's free, shared libraries being... well... shared, virtual memory
blowing smoke and throwing around mirrors, etc.).

However, I think it's safe to say that what is essentially an untouched
GUI frontend to Gmail should not register as taking up 248 MiB of my
physical memory! and neither should a couple of windows with some static
text and pictures in them just because of a few interface tweaks
(`Vimperator').

Why would the relatively unused Profiles 1 and 2 be taking up almost
twice as much memory as the much more heavily used Profile 1?

Could the long-lived Javascript programs that underly Vimperator and Gmail
be the culprits? Are they badly programmed? Is the Javascript engine badly
programmed?

Guys, please.

Surely the Laws of the Universe do not require 2/3 of my physical memory to
run 3 different profiles of a goddamn web browser. Even Profile 0 seems a
little rotund; I mean, FFS, that little guy alone uses enough memory to hold
16 fullscreen, 32-bit RGBA (that is, including alpha) dumps of my 1920x1200
resolution screen. WTF is Firefox doing?

Sincerely,
Michael Witten
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: Firefox fat on Javascript?

Boris Zbarsky
On 5/10/11 11:59 PM, [hidden email] wrote:
> Guys, what is going on here?

So to sum up:

1)  Your main browsing account takes 143MB of RAM.  That seems ok,
depending on what you have loaded, what sort of build this is, etc.

2)  Your browser with gmail loaded uses 248MB.  That may be right
depending on what you've done with gmail in the past.  Note that gmail
has a known memory leak wherein the memory it takes will increase while
the page is open.  This leak is due to the gmail scripts holding on to a
bunch of objects and keeping them reachable so they can't be GCed.  It
manifests in all browsers.  Google is working on rolling out a fix for this.

3) Your browser with Vimperator.  This could maybe use looking into; the
last time I ran a debug build in this configuration it asserted like
crazy due to all the invariants Vimperator was violating, so I wouldn't
be too surprised if there are issues here.

> However, I think it's safe to say that what is essentially an untouched
> GUI frontend to Gmail should not register as taking up 248 MiB of my
> physical memory!

Why not?

> and neither should a couple of windows with some static
> text and pictures in them just because of a few interface tweaks
> (`Vimperator').

Why not?  Maybe it should, maybe not.  Needs investigation.

> Why would the relatively unused Profiles 1 and 2 be taking up almost
> twice as much memory as the much more heavily used Profile 1?

Good question.  See above?

> Could the long-lived Javascript programs that underly Vimperator and Gmail
> be the culprits?

Yes.

> Are they badly programmed?

Yes.

> Is the Javascript engine badly programmed?

Maybe.

> Surely the Laws of the Universe do not require 2/3 of my physical memory to
> run 3 different profiles of a goddamn web browser. Even Profile 0 seems a
> little rotund; I mean, FFS, that little guy alone uses enough memory to hold
> 16 fullscreen, 32-bit RGBA (that is, including alpha) dumps of my 1920x1200
> resolution screen. WTF is Firefox doing?

about:memory (especially with Nicholas Nethercote's recent changes)
should be able to tell you some of that.

-Boris
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: Firefox fat on Javascript?

Michael Witten-2
On Wed, 11 May 2011 01:27:01 -0400, Boris Zbarsky wrote:

> On 5/10/11 11:59 PM, [hidden email] wrote:
>> [It seems reasonable for a browser to require at least 143 MiB of
>> physical memory.]

Maybe it is, but my intuition says otherwise; I doubt we will come
to a satisfactory conclusion in this discussion, so we'll leave it
at that.

>> Surely the Laws of the Universe do not require 2/3 of my physical memory to
>> run 3 different profiles of a goddamn web browser. Even Profile 0 seems a
>> little rotund; I mean, FFS, that little guy alone uses enough memory to hold
>> 16 fullscreen, 32-bit RGBA (that is, including alpha) dumps of my 1920x1200
>> resolution screen. WTF is Firefox doing?
>
> about:memory (especially with Nicholas Nethercote's recent changes)
> should be able to tell you some of that.

The data from about:memory for each firefox instance follows; for reference,
here are the descriptions of the 3 instances (each of which runs a different
profile):

  Profile                     Usage
  -------                     -----
     0       Reading news (aggregators and otherwise),
             watching YouTube and other Flash video,
             making `First!' posts on slashdot, reading
             technical documentation, searching for
             everything via Google, editing Wikipedia,
             etc. I pretty much do a little bit of
             everything with this instance and spend
             most of my time on the web using it.

     1       Basically just sitting there with one
             browser window opened to my Gmail account;
             I haven't been using it much lately... it
             has literally just sat there, unused with
             Gmail ticking in the background.

     2       Running Vimperator with a few of [what I
             think are] relatively static pages just
             sitting there; maybe I'll make an        
             occasional Google search, but it mainly
             goes unused.


Profile 0: (heavy usage)

  Overview
 
    Memory mapped: 217,055,232
    Memory in use: 159,548,300
 
  Other Information
 
    Description                            Value
 
    malloc/allocated.......................159,551,508
    malloc/mapped                          217,055,232
    malloc/committed.......................217,055,232
    malloc/dirty                             2,580,480
    js/gc-heap..............................32,505,856
    js/string-data                           3,484,380
    js/mjit-code...............................100,752
    images/chrome/used/raw                           0
    images/chrome/used/uncompressed............179,680
    images/chrome/unused/raw                         0
    images/chrome/unused/uncompressed................0
    images/content/used/raw                    893,214
    images/content/used/uncompressed........11,330,676
    images/content/unused/raw                      809
    images/content/unused/uncompressed...........1,024
    storage/sqlite/pagecache                 9,217,264
    storage/sqlite/other.....................1,537,152
    layout/all                               3,936,739
    layout/bidi....................................212
    gfx/surface/image                           79,112
    content/canvas/..................................2
    d_pixel_bytes                                    0

Profile 1: (Gmail)

  Overview
 
    Memory mapped: 367,001,600
    Memory in use: 222,837,828
 
  Other Information
 
    Description                            Value
   
    malloc/allocated.......................222,841,036
    malloc/mapped                          367,001,600
    malloc/committed.......................367,001,600
    malloc/dirty                             2,351,104
    js/gc-heap..............................97,517,568
    js/string-data                           6,139,150
    js/mjit-code...............................531,503
    storage/sqlite/pagecache                 6,041,992
    storage/sqlite/other.....................1,469,704
    images/chrome/used/raw                           0
    images/chrome/used/uncompressed............146,880
    images/chrome/unused/raw                         0
    images/chrome/unused/uncompressed................0
    images/content/used/raw                    214,097
    images/content/used/uncompressed...........350,396
    images/content/unused/raw                        0
    images/content/unused/uncompressed...............0
    layout/all                               2,782,929
    layout/bidi....................................462
    gfx/surface/image                           56,428

Profile 2: (Vimperator)

  Overview
 
    Memory mapped: 429,916,160
    Memory in use: 371,937,160
 
  Other Information
 
    Description                            Value
 
    malloc/allocated.......................371,940,320
    malloc/mapped                          429,916,160
    malloc/committed.......................429,916,160
    malloc/dirty                             2,019,328
    js/gc-heap.............................136,314,880
    js/string-data                           4,804,338
    js/mjit-code...............................229,488
    images/chrome/used/raw                           0
    images/chrome/used/uncompressed............133,060
    images/chrome/unused/raw                         0
    images/chrome/unused/uncompressed................0
    images/content/used/raw                  3,338,152
    images/content/used/uncompressed........29,185,369
    images/content/unused/raw                        0
    images/content/unused/uncompressed...............0
    storage/sqlite/pagecache                 4,865,440
    storage/sqlite/other.....................1,574,456
    layout/all                              11,508,560
    layout/bidi......................................0
    gfx/surface/image                          377,140
    content/canvas/..................................2
    d_pixel_bytes                            1,342,336

P.S.

For dubious reasons, Mailman munged the Message-ID of my last email,
which was:

  [hidden email]

and before Mailman will munge the Message-ID of this email,
it is:

  [hidden email]

If you add such munging to the fact that a user must subscribe to each
mailing list before posting, then I can safely say that Mozilla has one
of the worst communications infrastructures ever devised.
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: Firefox fat on Javascript?

Boris Zbarsky
In reply to this post by Boris Zbarsky
On 5/12/11 11:52 AM, [hidden email] wrote:
> The data from about:memory for each firefox instance follows

OK, so the gmail and vimperator ones have a much larger JS gc heap.
That's actual JS objects that are in use by whatever JS code is running,
and is consistent with the gmail and vimperator JS just creating a bunch
of objects and holding on to them.

The vimperator instance also has a bunch more images being used than the
other two instances, and a _lot_ more layout datastructures.  That's a
little odd and may indicate leaks in either vimperator itself or Gecko
in cases that vimperator tickles.

If you start a browser with vimperator showing nothing but about:blank
and do the same without vimperator (just use clean profiles for both,
with one having vimperator installed), how do the about:memory outputs
compare?

Also, if you are willing to try a nightly build that would give much
more readable and useful about:memory output; since the plan is to run
against a clean profile anyway it won't get in the way of your other builds.

> For dubious reasons, Mailman munged the Message-ID of my last email,

This may have something to do with the fact that I'm reading this group
and replying over NNTP, not e-mail.

> If you add such munging to the fact that a user must subscribe to each
> mailing list before posting

You can use either NNTP or Google Groups to avoid having to subscribe to
mailing lists, for what it's worth...

> then I can safely say that Mozilla has one
> of the worst communications infrastructures ever devised.

This, like your intuition about browser memory usage, is likely
something we're not going to come to agreement on.  ;)

-Boris
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: Firefox fat on Javascript?

Robert Kaiser
In reply to this post by Boris Zbarsky
[hidden email] schrieb:
> On Wed, 11 May 2011 01:27:01 -0400, Boris Zbarsky wrote:
>
>> On 5/10/11 11:59 PM, [hidden email] wrote:
>>> [It seems reasonable for a browser to require at least 143 MiB of
>>> physical memory.]
>
> Maybe it is, but my intuition says otherwise

I agree with you that a "browser" should be able to run with less
memory, but then, what we have in Firefox, Chrome, IE9, Safari, etc.
today are not "browsers" but "web runtimes", if you will. The collection
of lean documents that the web once was has evolved to being an
ever-growing application platform, and many of the often-used websites
today actually are more web applications than what "web pages" were
10-15 years ago.
And for the web application runtime engines that have become of our
"browsers" of old it's really reasonable to require that amount of
memory, esp. given the fact that even most smartphones sold today have
more available than that.

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 needs answers to. And most of the time,
I even appreciate irony and fun! :)
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Michael Witten-2
[Sorry for the repeat, Robert; I got ahead of myself.]

On Fri, 13 May 2011 00:57:29 +0200, Robert Kaiser wrote:

> [hidden email] schrieb:
>> On Wed, 11 May 2011 01:27:01 -0400, Boris Zbarsky wrote:
>>
>>> On 5/10/11 11:59 PM, [hidden email] wrote:
>>>> [It seems reasonable for a browser to require at least 143 MiB of
>>>> physical memory.]
>>
>> Maybe it is, but my intuition says otherwise
>
> I agree with you that a "browser" should be able to run with less
> memory, but then, what we have in Firefox, Chrome, IE9, Safari, etc.
> today are not "browsers" but "web runtimes", if you will. The collection
> of lean documents that the web once was has evolved to being an
> ever-growing application platform, and many of the often-used websites
> today actually are more web applications than what "web pages" were
> 10-15 years ago.
> And for the web application runtime engines that have become of our
> "browsers" of old it's really reasonable to require that amount of
> memory, esp. given the fact that even most smartphones sold today have
> more available than that.

I decided to run a test.

I killed X11 and then started it up again, giving me a fresh GUI environment
within my system (which has an uptime of almost 8 days); I then got a few
programs running, and here are the highlights:

  * 25% (252 MiB) of physical memory being used; no swap spaced being used.

  * 97 processes.

  * Linux kernel (uptime about 8 days) with some built-in live profiling
    and all of the debugging symbols.

  * 12 instances of the bash shell (one of which has been up for 8 days).

  * xmonad managing all of my X11 windows.

  * xmobar showing me live updates of CPU, memory, and network usage.

  * rxvt-unicode terminal emulator with a few extensions (including a built-in
    perl interpreter) running in daemon mode with 10 windows (4 of which have
    constantly updating text in the scrollback buffers).

  * Linux kernel source being built FROM SCRATCH after having pulled the
    latest with git; the output is being stored in a scrollback buffer of
    an rxvt-unicode window.

  * `screen' terminal multiplexer in an rxvt-unicode window and running
     the irssi IRC client (with perl extensions and a built-in perl
     interpreter), which is connected to freenode via Tor and joined to
     ##linux, which is being logged.

  * 2 8-page pdfs being scrolled in a loop automatically.

  * emacs running in deamon mode (uptime 1 day) with one emacsclient instance
    running in an rxvt-unicode window and another emacsclient instance running
    in an emacs GUI frame. Emacs FFS!

  * glxgears running smoothly.

  * 3 mplayer instances:
 
    - Baby Got Back mp3 looping with statistics in an rxvt-unicode window.

    - 640x360 and 640x480 h.264 videos of reasonably high quality playing on
      a loop with statistics in an rxvt-unicode window.

  * (I also opened up gimp and loaded an image that is 90 MiB uncompressed,
     but this brought the memory usage to 49%, again with no swap usage,
     which I figured wouldn't make as easy a comparison).

This is all going simultaneously, running my machine, managing power and
devices, connecting to the internet, responding to user input, performing
disk I/O and memory management, displaying fluid 3D graphics and the
multimedia content from several sources, editing files, online `info' pages,
statistics, scrollback buffers, logging, encryption, window management,
AAAAAAAAAaaaaaaaaaaaa!

... and it fits into just as much memory as Firefox on a good day when
I'm NOT using it as a next generation runtime (but rather as just a plain
old web browser pretty much of yore).

All I'm saying is that there is [probably] room for a lot of improvement,
especially if you fancy Firefox as a major `App' platform.

Sincerely,
Michael Witten
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

crowder-2
In reply to this post by Robert Kaiser
If you're using gmail and youtube, you're using your browser as an
"app platform".  These are not the 15k HTML pages "of yore".
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Michael Witten-2
On Fri, May 13, 2011 at 18:37, crowder <[hidden email]> wrote:
> If you're using gmail and youtube, you're using your browser as an
> "app platform".  These are not the 15k HTML pages "of yore".

I wrote:

>> ... and it fits into just as much memory as Firefox on a good day when
>> I'm NOT using it as a next generation runtime (but rather as just a plain
>> old web browser pretty much of yore).

I'm telling you there that I'm not using it for YouTube and Gmail.

Guys, please take an interest in performance in both space and time;
quit trying to blame the victim.
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Boris Zbarsky
In reply to this post by crowder-2
On 5/15/11 3:14 PM, Michael Witten wrote:
> Guys, please take an interest in performance in both space and time;
> quit trying to blame the victim.

Michael, please stop making baseless accusations of not having an
interest, ok?  ;)

-Boris
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Michael Witten-2
On Mon, May 16, 2011 at 02:20, Boris Zbarsky <[hidden email]> wrote:
> On 5/15/11 3:14 PM, Michael Witten wrote:
>>
>> Guys, please take an interest in performance in both space and time;
>> quit trying to blame the victim.
>
> Michael, please stop making baseless accusations of not having an interest,
> ok?  ;)

In the context of this particular thread ('But firefox is no longer
just a browser'), my accusations are not baseless.
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Clemens Eisserer
In reply to this post by Michael Witten-2
Hi,

> ... and it fits into just as much memory as Firefox on a good day when
> I'm NOT using it as a next generation runtime (but rather as just a plain
> old web browser pretty much of yore).

A Hummer will not consume less than a small green car, just because
you drive it slow.

Yes, FireFox uses quite a lot of memory, so do the other major browsers.
On machines with less memory, it caches more carefully.
A lot is used for caching content like images and scripts, another
part for places and all the session data your browser keeps around.

- Clemens
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Michael Witten-2
On Fri, May 27, 2011 at 10:48, Clemens Eisserer <[hidden email]> wrote:
> Hi,
>
>> ... and it fits into just as much memory as Firefox on a good day when
>> I'm NOT using it as a next generation runtime (but rather as just a plain
>> old web browser pretty much of yore).
>
> A Hummer will not consume less than a small green car, just because
> you drive it slow.

The beauty of software is that it is not constrained like hardware.

Firefox should scale itself accordingly.

> Yes, FireFox uses quite a lot of memory, so do the other major browsers.

"Everybody's doin' it" is not that great an excuse; it could well be
that everybody is driving a gas-guzzling SUV because that's the only
kind of car that is possible to make, but I doubt that very much.

> On machines with less memory, it caches more carefully.
> A lot is used for caching content like images and scripts, another
> part for places and all the session data your browser keeps around.

Maybe this needs to be rethought.

Are such resources being cached in working memory? Maybe most
resources should be cached explicitly on disk so that my kernel
doesn't inadvertently swap out my other running programs to make space
for a bunch of LOLcat images that MIGHT be opened again.
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Robert Kaiser
In reply to this post by Clemens Eisserer
Michael Witten schrieb:
> Are such resources being cached in working memory? Maybe most
> resources should be cached explicitly on disk

Well, there's always a memory vs. speed tradeoff here. Of course, we
could optimize for using as little memory as in any way possible, which
just would mean a very significant cost in speed, depending on how far
we go. I tend to think of this in terms of "buying memory is cheap,
buying time isn't".

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! :)
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance
Reply | Threaded
Open this post in threaded view
|

Re: 'But firefox is no longer just a browser' (Firefox fat on Javascript?)

Michael Witten-2
On Fri, May 27, 2011 at 14:27, Robert Kaiser <[hidden email]> wrote:
> Michael Witten schrieb:
>>
>> Are such resources being cached in working memory? Maybe most
>> resources should be cached explicitly on disk
>
> Well, there's always a memory vs. speed tradeoff here. Of course, we could
> optimize for using as little memory as in any way possible, which just would
> mean a very significant cost in speed, depending on how far we go. I tend to
> think of this in terms of "buying memory is cheap, buying time isn't".

You are indeed correct that it is slower to read data from disk rather
than working memory; I am reminded of this fact everytime Firefox
shoves my other programs' working memory to disk.

So, I say this tradeoff should be exposed to the choice of the
individual user: I would rather have a slower Firefox cache than a
slower overall computing system (and a memory upgrade is not
possible).

Having Firefox read from my local disk is likely much faster and
bandwidth conserving than having it read from a remote server on the
Internet, so the cache is still quite useful even if it has been put
on disk.
_______________________________________________
dev-performance mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-performance