'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