Firefox fat on Javascript?
mfwi...@gmail.com
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
Boris Zbarsky
> 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
mfwi...@gmail.com
> On 5/10/11 11:59 PM, mfwi...@gmail.com 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:
b0761390-db74-40b2-80e...@gmail.com
and before Mailman will munge the Message-ID of this email,
it is:
838c493d-d261-4e1b-a34...@gmail.com
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.
Boris Zbarsky
> 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
Robert Kaiser
> On Wed, 11 May 2011 01:27:01 -0400, Boris Zbarsky wrote:
>
>> On 5/10/11 11:59 PM, mfwi...@gmail.com 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! :)
Michael Witten
On Fri, 13 May 2011 00:57:29 +0200, Robert Kaiser wrote:
> mfwi...@gmail.com schrieb:
>> On Wed, 11 May 2011 01:27:01 -0400, Boris Zbarsky wrote:
>>
>>> On 5/10/11 11:59 PM, mfwi...@gmail.com 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
crowder
"app platform". These are not the 15k HTML pages "of yore".
Michael Witten
> 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.
Boris Zbarsky
> 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
Michael Witten
In the context of this particular thread ('But firefox is no longer
just a browser'), my accusations are not baseless.
Clemens Eisserer
> ... 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
Michael Witten
> 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).
>
> 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.
Robert Kaiser
> 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
Michael Witten
> 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.