Performance:Home Page

This page is meant to provide a starting point for developers who want to improve performance in Gecko and Firefox. The list below focuses on the performance projects that we think will have the biggest impact. Each task includes a brief description and links to additional resources.

Startup Performance

Reduce startup workload

We should be able to greatly reduce the amount of work needed to bring up the Firefox browser window. Today, it loads a bunch of extra stuff that really could be delayed until it is needed. Phoenix 0.1 started up very quickly because it was a simple XUL browser! ;-)

Possible areas for improvement:

  * Put components which aren't typically needed at startup into external dlls, to reduce the amount of code that has to be paged in
  * Fastload XBL bindings
  * ...

Move FF to XULRunner (investigate at least)

A trimmed down XUL browser application based on xulrunner loads much more quickly than FF 1.5, and uses significantly less memory (on the order of 14 vs 26 megabytes of memory). We need to understand why, and more importantly figure out how to trim the size of FF's memory footprint accordingly. This may mean moving FF to xulrunner, or it may mean applying something else that we learn from the investigation. At any rate, we know it should be possible to show the user's homepage using significantly less memory than we do now, which should help startup performance.

Preload FF at system start

Bring back Mozilla quick launch, but do it better ;-) Possibly build an extension that could be used with FF 1.5 to enable this functionality.

Javascript Component Loading

Even with fastloaded (precompiled) javascript components, we spend a fair amount of startup time deserializing large scripts. Things to do:

  * Refactor large components (nsExtensionManager.js, nsUpdateService.js) to load the minimal amount of code at startup
  * Eliminate locking in the JS engine when deserializing scripts, see bug http://bugzilla.mozilla.org/show_bug.cgi?id=312238
  * Use a large pool of memory for allocating strings during deserialization, see https://bugzilla.mozilla.org/show_bug.cgi?id=279839#c11

Function Ordering

All of the major platforms support having the linker reorder functions in the binary. We can exploit this to move the functions that are needed at startup into a contiguous section at the start of the binary, which should reduce the time spent reading from disk.

  * Profile the startup process to generate an optimal function ordering
  * Integrate the ordering into the build system

Improve Fastload system

The Fastload system is used to load precompiled javascript, preparsed XUL, and soon preparsed CSS at startup. The system is currently designed to be architecture-independent, which makes it impossible to write large chunks of memory at once (differences in endianness, data sizes, and struct packing). We could drastically reduce the time spent reading the fastload file by changing to an architecture-dependent, memory-mapped file that could be accessed directly.