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

Michael Witten <[email protected]> Fri, 13 May 2011 05:43:15 +0000
Newsgroups gmane.comp.mozilla.performance
Message-ID <[email protected]>
[Sorry for the repeat, Robert; I got ahead of myself.]

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

> [email protected] schrieb:
>> On Wed, 11 May 2011 01:27:01 -0400, Boris Zbarsky wrote:
>>
>>> On 5/10/11 11:59 PM, [email protected] 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