Firefox/Feature Brainstorming:Performance

Make jQuery's code native. sounds crazy :)

Make it possible to have firefox started as a new process with a switch (firefox.exe -np) to be able to have two instances running in case you are testing something that crashes the browser often while you are in some deep and nested back-end at the same time. it is very annoying that when it crashes all is lost. Yes - i could use another browser for the back-end stuff but why would i?

firefox.exe -no-remote -P otherprofile

Note: This is partly already possibly with the environment variable MOZ_NO_REMOTE set to 1.

Like you can have multiple instances of IE running

Be the fastest browser on the market, not only on "fat" desktops, but also on bargain desktops with only 256MB of RAM. More other, when firefox is reduced on the taskbar, the memory use doesn't decrease on the opposite of Opera and....IE7.Reference:(in french)[1]

Mark Wilton-Jones' browser speed benchmarks

Try to implement an internal memory manager. It should, for example, pre-allocate about 10% of ram memory and try to operate within that memory. All calls to "free()" should release memory to this global memory pool and all calls to "malloc()" must allocate memory from this memory pool. If properly implemented, we can even reduce the overheads that may arise due to such an implementation.

Keep to improve the browsing velocity .Reference:[2]

One feature I would like to see is faster startup times and less memory hogging as at the moment I think that ff takes a long time to boot up the 1st time but less time after that so I think a preloader would be a good idea and I also agree in trying to sandbox the browser/extensions to a defined amount of memory Therefore make the browser work faster.

Improve browser launch time on both Windows and Mac OS X. Currently IE and Safari launch much more efficiently, making it more sensible to open one of those browsers when quickly looking something up. Enduring the sluggish launch time again and again makes for an irritating experience.

n/a

Integrate a FF Preloader into the program. Currently the Preloader for Firefox 1.0 doesn't work for 2.0. A preloader option within FF that allows the user to choose whether to preload certain parts of FF could improve the boot time dramatically.

n/a

At the very least, bring up a UI as quickly as possible. Show the splashscreen while loading. Often I find I don't know whether Firefox has started up and start up multiple copies.

n/a

Bring speed up to par with Safari/Opera on the Mac platform. Perhaps bring project into XCode/Objective-C/Cocoa? The Cocoa API is much more feature complete than the Carbon API, since the latter is more of a carry over from MacOS 9. With Cocoa, things like integerated spell checking would come 'free', since they are associated with the widgets being used.

n/a

Hardware accelerated graphics (perhaps use the Vista/Mac OS X/AIGLX/XGL engines to do the acceleration for us)

n/a

Make the javascript engine less cpu hungry. On a security and programmation site, I saw: the javascript engine of firefox is a nice untidiness, what is a security and perfomance failing.

n/a

Do more caching of the DOM. E.g. stacking several PNG-Images with alpha channel slows down the browser dramatically, even for unrelated DOM changes.

n/a

Make the textarea performance better. Often, even on fast machines, I can type faster than the text appears. This doesn't happen all the time, but does often enough. As it catches up to me, I see all of the text in the textarea being cleared and flashing up for each character typed.

n/a

It is very annoying to be typing into a text box and have the browser go unresponsive for a few seconds while in the middle of typing. This is caused by Javascript in other windows (like gmail) waking up and using the network. Threading needs work to fix this.

n/a

Stability and resource-utilization improvements

Put each document into an independent process (not thread: separate forked process) so that:

• When a document causes Firefox to crash, the whole browser won't be taken with it.
• When a bug in Firefox stomps on memory it doesn't own, other documents in memory are not corrupted.
• When a document causes Firefox to leak massive amounts of memory, closing that tab or window will free up the wasted memory.
• Memory fragmentation: If I open three documents, then close the second one, no memory is returned to the OS for other apps, because memory is only freed to the OS from the end of the heap. Also, however, I notice that if I open one document (and check the memory size), then open two more, then close the last two, the process size does not shrink back to what it was with only the first document (this looks like a memory leak). Putting each document into its own address space would solve these problems, because processes that terminate free all of their memory to the OS.
• When a bug in Firefox or a script on the page locks up (infinite loop or whatnot), the whole browser will not hang up, just the one document. Closing the tab or window kills the aberrant process. This is also an issue for DNS lookup; the browser always freezes completely during DNS lookup. Make this affect only the document being loaded.
• Obviously, this also means that the Firefox main UI should also be in a separate process, and you should use IPC and sharing of window-system resource IDs and handles to communicate between UI and document processes.
  • (1) I'm not suggesting that document processes should push all of their UI interaction and rendering through the main UI process. Rather, the main UI should share with document processes the resource-id/surface handle for the window that the the document will be rendered in. This way, the document process will communicate directly with the X server or GDI. This should minimize the IPC between the document and UI processes. The catch is that the documents should survive loss of these resources and be able to change where they're rendering to when the UI comes back up and reconnects.
  • (2) The alternative to (1) would be to abstract the rendering and UI interaction so that document processes use an API and IPC to get access to the windows. This would be bad for a number of reasons:
    • The extra IPC would hurt performance.
    • This pushes too much of the work back from the document process into the UI process, making it a CPU bottleneck and making it more likely that a single bug will take down the whole browser.
    • More information about different documents is in a central location, reducing security.
• When the UI crashes, restarting the UI can sweep up documents that find themselves unattached and re-present them undisturbed.
• Cross-site scripting and buffer overflow exploits have a much harder time hacking into information for other documents, because they are inaccessible in separate processes.
  • To secure a process on Linux, simply write to the /proc/self/seccomp file. The process will then only be able to communicate via existing file descriptors (be sure to close the X11 one) and existing shared memory regions. Only about four system calls are allowed for a process in secure mode: read, write, exit, and signal handler return.
• Provide an about:top view that gives an accounting of which documents and plugins are using how much memory and CPU time.
• Provide a centralized UI for dynamically charting how much CPU and memory is used by each tab. As many tabs being opened, it gets hard for none script avid users to hunt down wich tab is causing firefox to drain up system resource. With a centralized UI, every user would be able to find out which tab/site is causing resource drainage
• Point of clarification: The word "document" here is used loosely. I am referring to what the USER would think of as a document. Perhaps better substitutions for "document" here would be "independent DOM tree", "user-facing document", or others. For instance, if a web site uses an iframe, that frame is, in a sense, a separate document. But it's part of the same web page, and data may be shared between it and the containing document. Thus, they should be in the same process. On the other hand, if I load "mail.yahoo.com" into one tab, and "slashdot.org" into another tab, they are completely unrelated and should therefore run in separate processes. Things become a bit iffy if a web site launches another document in a separate tab or window yet expects to be able to communicate with it. You'd need to be able to detect which situation it is and fork another process or not as appropriate.
  • I'm doing some work on this problem, which suggests that "document" or "page" isn't the right unit. To avoid breaking pages that can talk to each other via JavaScript, you want something closer to "process-per-domain." This almost corresponds to the browser's "same-origin" security policy for scripts. Essentially, pages that can talk over JavaScript can still work, but pages from different domains (e.g., Yahoo and Slashdot) can't interfere with each other. I'm putting up a more complete writeup on my user page. --Csreis 17:23, 17 October 2006 (PDT)

- Making Firefox More Robust, from csreis

Include a language-neutral VM for a back-end for javascript. The benefits are quite significant, and include: JIT compling, with caches of compiled code (done when the VM is not busy); a better sandboxing model for compile-time overruns and exception handling; better threading model for managing multiple windows and tabs; language-neutral interface for extending or replacing the runtime language (i.e. changing it from something like "javascript-1.7" to "moz-cli-1.0", so that languages like Ruby and Python could be compiled into the cli); easier to add libraries of code to the base distribution or from external sources (code libraries that people could download to their computers and use for certain sites); the introduction of a unified object/exception/type model. Perhaps less important reasons include: businesses might be a little happier because their code wouldn't be completely "transparent" as it travels across the net if it's possible to send it already compiled to a person's computer; it might make it possible to add extensions, like signed code or an abstract threading model.

n/a

Now multi-core CPUs are becomming standard it makes sense to improve multi-threading. Javascript or rendering on one tab should not lock up other tabs, for example. Even within a tab, image decoding, scripting, plugins and HTML rendering could all be separated.

n/a

n/a

n/a

n/a

Browser Loading Time

• Make the browser open faster; that is the number one reason that I have heard for people not using Firefox or switching to Firefox

• One solution could be to allow for an option to start Firefox on O.S. startup then drop to tray for instant access (always-on), and any time Firefox is opened from any shortcut or icon it pulls up from the tray instance.
  

kind of like this: https://addons.mozilla.org/firefox/2110/

https://addons.mozilla.org/firefox/2110/

• An other part of the way to improve the start delay is checking for updates less frequently, not all startups, or doing this check with an asynchronous way. By unchecking the preference to check for updates, the startup is more or less instantly on my windows.

Sleep invisible pages! Especially Flash movies!

You all know those fancy Flash banners we have nowadays. Some websites even show two of them on one page. If I open 10 of those pages in separate tabs: with Firefox 2.0 there will be 20 Flash movies playing in the background and my PIV 3.0Ghz will hit 100% and everything will start to slow down. After a while Firefox will become sluggish and non-responsive.
I'd even go as far as to say that Javascript and Actionscript are currently using up the most of my overall PC resources.

So my suggestion would be: if pages are invisible (e.g. inside inactive tabs), let them sleep temporarily until the page becomes visible again. Or at least pause those Flash movies temporarily.

Firefox should save energy

• Develop new features as extensions (enabled in the default install) so that they can be disabled if un-needed. We MUST avoid bloat to stay in the lead, and forcing new features on people that just want a clean experience is not in our best interest (see More vs Less section, concepts of Firefox Core + Firefox More).

n/a

• Develop a set of Official Extensions such that most of these new features (and some of the old features) can be made optional for the basic user. Firefox's strength is that it is a low weight (rather than a kitchen sink+) browser. Creating Official Extensions which expand the useful feature set, but are optional, will keep Firefox lean and mean (see More vs Less section, concepts of Firefox Core + Firefox More).
• Facilitation of console manipulation tools. It would be nice to be able to bring up a console in Firefox and use various tools to manipulate the page 'on the fly'. More precisely, it would be good if developers were able to easily write interfaces for doing this. For example, it would be nice if it was easy for someone to write a console tool that manipulates the DOM with Hpricot or BeautifulSoup. (Make it easy/feasible to write Chickenfoot like extensions).

Keep to improve the browsing velocity .Reference:[3]

Make the above extensions automatically loaded when they are needed, but not loaded initially. This saves memory and speeds up startup time and page load time.

Radical Change? Maybe Not?

O.K. I know it's Tiring Hearing/Viewing this, but I'll Keep it Short as I can:
System Resources are a Major Factor to Consider. Firefox Hogs a lot of CPU it Doesn't Necessarily need Sometimes. It Also Hauls/Hangs/Stalls Huge amounts of CPU when Apparently Doing Nothing (Bug? Leak?). It Also Hogs a lot of Virtual Memory, More then Twice that of IE. And although, it doesn't Take long for Firefox to Load, it IS Noticeably Slow. Greater Acceleration is Needed/Appreciated In this area. Perhaps JAVA has A lot to do with some of the Downsides/Shortcomings of Firefox. Is a Complete/New Compilation of Firefox Under a More Favorable Language, Out of the Question? Perhaps C++? OR, Is it at all Possible to overcome, this, Shortcoming?

Pardon, I would also Like to add a Couple more things As I believe is relevant and Don't seem to see another place for these in terms of, Sections:

If a page stalls in Firefox, you must restart the Page again for it to Load Correctly. (Not necessarily cached. Be better if Firefox can just load the missing parts only, then go back and recheck the ones that were previously loaded.)

Links within sites do not load in a separate process. I have to wait for the main page to load first before any of the other Links I click even try to begin to Load.(In IE, I don't have to wait till the main page loads so I can check the other links within the site. It's a big deal for me.)

I have also Noticed this:

Clicking the Scroll button on the mouse sends more "load" to the load bar. (It gives a false sense of how much is Actually left to load.)
*Sorry, That probably doesn't go here.*

Welp, that Said any:
Objections?
Concerns?
Mitigation?
A More Informative Explanation as to Why this can't, or has yet to be Implemented?

N/A